live optics что такое

Live Optics

Optimize your IT spend with instant cloud pricing

Real-world data for IT decisions: From unstructured data to IT solutions.

Live Optics is free, online software you can use to collect, visualize and share data about your IT environment and workloads. Live Optics provides data analysis to help you understand your workload performance, so that buyers and IT providers can simplify discovery and have a mutual understanding of project requirements.

Optimize spending and analyze opportunities for virtualization or data center expansion.

Live Optics data analysis covers several areas in the IT infrastructure space

Aggregating and analyzing data from individual storage, data protection, server and file systems to make purchasing decisions can lead to overspending. To optimize your infrastructure for cloud readiness, you need to understand how workloads impact each other in a shared environment over time. Live Optics creates transparency, so you can accurately see and diagnose your unique IT needs and control the buying process. See for yourself the capabilities of our IT infrastructure portfolio in a virtual lab setting.

Server and Cloud

Live Optics data analysis covers IT infrastructure by providing IT professionals with live inventory and performance insight of hosts and VMs regardless of platform or vendor, helping to record and communicate their achieved benchmarks, workloads, or support concerns to others to accelerate decision time and reduce risk.

Workloads

Workloads provides insights such as machine and installation details, supported SQL-specific features, a list of databases, database size, and more. This type of insight is beneficial to understand what databases are within which instance and on what host the SQL Database is installed, which is perfect for inventory taking.

Unstructured data is one of the fastest growing data categories in the world. Live Optics is designed to bring insight to unstructured data through rapid characterization of storage growth, files types, and predictive potential for data archive, compression, or deduplication.

Storage

Live Optics creates a detailed breakdown of vendor and model specific data storage hardware including inventory, configuration, and performance history used for either validating the value of a recently deployed environment or assessing legacy equipment for replacement.

Data Protection

Live Optics provides insight into vendor specific backup software and appliances, data protection configuration, cycles and policies, and the front-end capacity of systems that are being protected.

Get insights into your IT infrastructure with Live Optics today.

Gathering workload characteristics and performance detail is a problem that most IT departments avoid due to complexity or resources. This often results in overdesign, overspend, and frustration in a support, expansion or purchasing cycle. Live Optics puts this information at your fingertips and is open to any end user at no cost or obligation. It’s quick and easy to sign up and start gaining insights into your IT infrastructure.

Collect

Capture performance, software, OS distribution and VM data for time frames ranging from a few hours to one week.

Источник

1С в облаке: типичные ошибки при миграции и как их избежать

Привет, Хабр! Меня зовут Николай Араловец, я эксперт по облачным технологиям в #CloudMTS.
Периодически я общаюсь с заказчиками, которые либо уже перенесли 1С в облако самостоятельно, либо только собираются это сделать. У каждого такого заказчика возникают свои сложности:

Поясню сразу: материал будет полезен для компаний, которые планируют размещать базы данных и приложения 1С в облаке.

Пул задач зависит от того, на каком этапе переноса 1С в облако находится заказчик. Мы по отдельности рассмотрим проблемы тех, кто только собирается переезжать, и тех, кто уже разместил 1С на площадке провайдера.

Сложности при размещении 1С в виртуальной инфраструктуре

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

Аппаратная конфигурация сервера в облаке

Для начала стоит узнать, какое физическое оборудование (compute node) использует сервис-провайдер и какие варианты его использования доступны. Для крупной инсталляции 1С (несколько сотен пользователей) оптимальным будет вариант размещения в выделенном вычислительном кластере, где используются серверы с высокочастотными процессорами (от 3 ГГц на ядро) и есть возможность выдать требуемый объем оперативной памяти на одну ВМ. На режим Intel Turbo Boost советую внимания не обращать: в виртуальной среде поведение гипервизора и ВМ на оборудовании с этой активированной опцией сильно отличается от поведения на bare-metal серверах.

Обязательно уточните, какие именно процессоры используются в серверах. Зачем это нужно? Например, в ряде конфигураций приложение и базу данных рекомендуется размещать на одной ВМ. Поэтому для нагруженной базы данных (MS SQL, PostgreSQL) может потребоваться определенное количество vCPU (более 4 vCPU) и оперативной памяти (от 64 Гб). Конечно, провайдер может предложить процессоры с тактовой частотой 3.8 ГГц на ядро — например, Intel® Xeon® Gold 5222. Однако у них всего по 4 ядра на сокет, поэтому есть риск, что у вас просто не получится выдать достаточное количество ядер и оперативной памяти машине, на которой будет работать связка «приложение 1С + СУБД». Очевидно, что это негативно отразится на общей производительности решения.

Хранилище в облаке

Как правило, наиболее популярный способ организации облачного хранилища у любого провайдера — общие хранилища (shared storage). Они могут быть реализованы на базе различных технологий — как проприетарных, так и с открытым кодом. Однако заказчик в любом случае должен понимать, что:

Для правильного сайзинга перед выбором вариантов где будут размещаться виртуальные машины соберите статистику по счетчикам дисковой подсистемы на серверах СУБД и базы данных на on-prem сайте. Это можно сделать самостоятельно — есть общедоступные инструменты для этого. Например, встроенный в Windows Server Performance Monitor со множеством счетчиков (disk, CPU, memory). Кроме этого я могу порекомендовать портал Live Optics — он предоставляет отчеты по нужным показателям производительности, в том числе и по дисковой подсистемы. Если возникнут сложности, не стесняйтесь обращаться к провайдеру: например, мы в #CloudMTS всегда готовы помочь со сбором нужных данных.

Безусловно, можно запросить выделенную конфигурацию аппаратного сервера с локальными NVMe дисками. Но будет ли она иметь отношение к облаку — вопрос.

При развертывании терминального сервера для доступа к 1С, производительность всей системы будет напрямую зависеть от доступности и пропускной способности канала между офисом/складом/магазином и облаком.

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

Чтобы избежать проблем, выбирайте провайдера с независимыми аплинками от двух поставщиков. Это можно сделать, например, проверив анонсы подсети провайдера через RIPE.

Далее подберите и как следует протестируйте ширину каналов между облаком и внутренней инфраструктурой (при больших расстояниях могут потребоваться корректировки TCP-параметров на уровне точек терминации трафика) и проверьте, что потери на канале не влияют на скорость.
Запрашивать сразу широкий канал смысла не имеет: по моему опыту, 9 из 10 заказчиков, которые запросили канал в 1 Гбит/c, не использовали его пропускную способность даже на 25%.

Механизмы отказоустойчивости

Доступность приложения и БД может быть реализована различными способами. На мой взгляд, наиболее правильный вариант — реализовать доступность на уровне приложения и/или БД с помощью кластеризации, always-on и прочих репликаций. Тем не менее, стоит уточнить у сервис-провайдера, какие механизмы отказоустойчивости присутствуют в облаке «by design» и как их можно использовать для повышения доступности.

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

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

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

Проблемы с производительностью 1С в облаке

Мой опыт работы (8 лет на различных позициях) в облачном сервис-провайдере показывает: если заказчик переносит данные без проработанного сайзинга и учета специфики облачной инфраструктуры, то у него рано или поздно возникнут сложности. Давайте посмотрим, в чем прячется «корень зла» и как устранить уже появившиеся проблемы.

Ошибки сайзинга

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

Каждый современный гипервизор, развернутый на x86_64 архитектуре, представляет ресурсы (CPU, memory) в виде NUMA-нод, базирующихся на сокетах. Для однопоточных приложений — а 1С именно к таким и относится — накладные расходы на переключение контекста между сокетами могут значительно влиять на производительность.

На скриншоте ниже — результаты теста Гилева для двух виртуальных машин, размещенных на одном физическом сервере с 4 сокетами по 18 ядер. Одной виртуальной машине выделено 16 vCPU (1 vCPU = 1 сокет), второй — 42 vCPU (2 сокета по 21 vCPU). Результаты говорят сами за себя:

1. Тесты связки 1С 8.3 и MS SQL 2016, платформа Win2016, настройки BIOS штатные для облака, настройки ESXi штатные для облака; Конфигурация VM – 42 vCPU, 3 GHz (2 сокета, нарушение распределения по pNUMA), 64 Gb mem.

2. Тесты связки 1С 8.3 и MS SQL 2016, платформа Win2016, настройки BIOS штатные для облака, настройки ESXi штатные для облака; Конфигурация VM – 16 vCPU, 3 GHz (16 сокетов), 64 Gb mem.

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

Проблемы на канале связи

Тут сразу начну с примера из личной практики. Однажды к нам обратился заказчик, у которого резко упала производительность 1С: значительно увеличилось время выполнения определенных операций.

Разбирая тикет, наша служба поддержки проверила канал от офиса заказчика до его терминального сервера в облаке и выявила около 30% потерь. При этом они приходились на «последнюю милю», через которую подключен офис. После решения проблемы с каналом время выполнения операций вернулось к прежним значениям.

Особенности сайзинга 1С

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

Сайзинг 1С, в первую очередь, зависит от конфигурации приложения. Можно выделить три типовых конфигурации:

Два других варианта требуют детального подхода к тестам.

Любителям использовать для тестирования утилиту Crystal Disk Mark рекомендую брать одну из последних версий, 7.x, для тестов. В них есть возможность замерять значения в MB/s, IOPS и время отклика (latency) дисковой подсистемы для конкретного теста, а также менять параметры.

Рекомендации по сайзингу 1С в облаке

Перейдем к практическим рекомендациям, которые помогут при сайзинге.

Выбор аппаратных конфигураций под размещение сервисов 1С

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

В среде виртуализации есть ряд существенных отличий, которые значительно влияют на поведение этого режима. Например, его активация на уровне BIOS аппаратного сервера не означает, что тактовая частота виртуальных процессоров на уровне гостевой ОС будет отображаться как максимальная тактовая частота, заявленная для физического процессора. Более того, современные многоядерные процессоры не в состоянии выставить максимальную тактовую частоту для всех ядер одновременно, так как они ограничены параметром TDP (Thermal design power, «расчетная тепловая мощность»).

Приведу пример. На процессоре Xeon 6254 с базовой тактовой частотой 3.1 ГГц, заявленная максимальная тактовая частота — 4 ГГц. При активации режима TurboBoost на сервере с 4 процессорами 6254 и включенным режимом Power Management = High Performance, утилита esxtop без нагрузки показывает прирост не более 20% на каждое ядро. В действительности вы увидите реальный рост частоты на уровне виртуальной машины, только запустив ее на конфигурации с 1 vCPU, без какой либо сторонней нагрузки на аппаратном сервере, где размещена эта виртуальная машина. Даже если запустить эту же ВМ, например, в конфигурации с 8 vCPU, прирост частоты на каждый виртуальный процессор будет минимальным.

Сайзинг дисковой подсистемы

Ключевые показатели для СУБД — количество операций ввода/вывода в секунду и время отклика (IOPs и Latency). Оптимальным вариантом для сайзинга будет снятие замеров с текущей рабочей системы заказчика (например с помощью портала Live Optic). Расчет в этом случае будет базироваться на реальных показаниях.

Выделение локального сервера с NVMe дисками не имеет смысла. Такой подход не учитывает требования к отказоустойчивости и резервированию инфраструктуры и является избыточным в 99,9% случаев сайзинга, с которыми мы сталкивались. При необходимости мы как сервис-провайдер можем предоставить выделенный iSCSI LUN, выдаваемый напрямую в гостевую операционную систему, что позволяет снизить накладные расходы на виртуализацию.

Ширина канала

Прежде чем запрашивать 1 Гбит/с, убедитесь, что вы реально будете использовать хотя бы 20% от этой цифры. Или включите мониторинг — это позволит оптимизировать расходы в ходе эксплуатации.

Конфигурация виртуальных машин

Банальные, но важные советы:

Советы по работе с 1С в облаке

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

1. Принимать активное участие в работе по тикетам, связанным с производительностью.

Конечно, можно просто написать запрос в службу поддержки и ожидать, что все проблемы будут устранены в соответствии с SLA. Однако тикеты, связанные с производительностью, почти невозможно решить без знания инфраструктуры заказчика.

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

2. Запрашивать у сервис-провайдера любую информацию, которая поможет ускорить работу сервиса.

Например, конфигурацию BIOS аппаратных серверов, на которых размещаются виртуальные машины. Настройки по умолчанию в облаке #CloudMTS таковы, что на процессорах с базовой тактовой частотой ядра в 3 ГГц при правильной конфигурации ВМ, заказчик, размещая 1С и MS SQL, получит в тесте Гилева не менее 33-35 «попугаев». Если вынести виртуальную машину в выделенный кластер, на такой же виртуальной машине при такой же частоте процессора их количество может вырасти уже до 42.

3. Постоянно анализировать быстродействие сервисов 1С в облаке

А не только когда появляется очевидная деградация. Делать это можно с помощью интегрального инструмента оценки APDEX, который даст существенно более объективную оценку быстродействия в сравнении с тестом Гилева (про APDEX можно почитать тут и тут).

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

В завершение статьи я хочу отметить, что после выбора сервис-провайдера и сайзинга заказчик оказывается перед более трудной задачей — миграцией своих сервисов в облако. Например, с командой #CloudMTS можно обсудить:

А если вы планируете переносить 1С в облако, советую обратить внимание на наш специализированный хостинг. Вы можете выбрать подходящий по стоимости сегмент ресурсов, а специалисты #CloudMTS подберут оптимальную конфигурацию, настроят инфраструктуру и при необходимости помогут перенести данные. А для тех, кто работает с персональными данными, есть защищенный сегмент 152-ФЗ.

Источник

Anyone used live optics?

I am dealing with a few server vendors and a few of them have mentioned this product called live optics. Which I guess snapshots the performance, etc of the server. I ran it by our one admin and they seemed a bit un-sure of it and what other data it may collect. The admin said check with some contacts and see what they say, then run it by our other admin and see what they say.

I think if dell, starwind, VMware, etc use it it should be fine, but that is not always a foolproof vetting process for a software. I am also a bit unsure I want to load something extra onto a server that would add attack surface. If it is a portable or runs from a PC then maybe I wouldn’t mind as much.

4 Replies

It is the new version of Dell’s Dpack tool.

For their privacy policy see here:

Dara IT is an IT service provider.

Dell do not use it, Dell own it. It is their product.

In the not too distance past as a Dell partner, Dell have gone around us and directly to the end client to pitch solutions. So if Dell quotes me a buy price at 10k and I sell at 11k, Dell then swoops in and offers it to the client for 8k.

«Dell EMC Live Optics™ is an industry standard method of impartially documenting server/storage configuration and performance as well as observing file characteristics of data. » https://www.liveoptics.com/about-live-optics/

Do I trust Dell not to screw me over by harvesting data on my clients and using them for nefarious purposes? What are they getting out of this?

The website has almost no details, no privacy policy, no data protection info for GDPR. What is their angle? Even on the support site there is almost no details about this product in terms of data collection, what it is collected for, etc.

EDIT: Justin above found a privacy policy in the app itself but its nowhere on the marketing page or support site.

Источник

То, что вы хотели знать про оптический поток, но стеснялись спросить

Что же такое оптический поток

Оптический поток (ОП) – изображение видимого движения, представляющее собой сдвиг каждой точки между двумя изображениями. По сути, он представляет собой поле скоростей (т. к. сдвиг с точностью до масштаба эквивалентен мгновенной скорости). Суть ОП в том, что для каждой точки изображения находится такой сдвиг (dx, dy), чтобы исходной точке соответствовала точка на втором изображении . Как определить соответствие точек – отдельный вопрос. Для этого надо взять какую-то функцию точки, которая не изменяется в результате смещения. Обычно считается, что у точки сохраняется интенсивность (т. е. яркость или цвет для цветных изображений), но можно считать одинаковыми точки, у которых сохраняется величина градиента, гессиан, его величина или его определитель, лапласиан, другие характеристики. Очевидно, сохранение интенсивности дает сбои, если меняется освещенность или угол падения света. Тем не менее, если речь идет о видеопотоке, то, скорее всего, между двумя кадрами освещение сильно не изменится, хотя бы потому, что между ними проходит малый промежуток времени. Поэтому часто используют интенсивность в качестве функции, сохраняющейся у точки.

По такому описанию можно перепутать ОП с поиском и сопоставлением характерных точек. Но это разные вещи, суть оптического потока в том, что он не ищет какие-то особенные точки, а по параметрам изображений пытается определить, куда сместилась произвольная точка.

Есть два варианта расчета оптического потока: плотный (dense) и выборочный (sparse). Sparse поток рассчитывает сдвиг отдельных заданных точек (например, точек, выделенных некоторым feature detector’ом), dense поток считает сдвиг всех точек изображения. Естественно, выборочный поток вычисляется быстрее, однако для некоторых алгоритмов разница не такая уж и большая, а для некоторых задач требуется нахождение потока во всех точках изображения.

Для вырожденных случаев можно применять более простые методы определения сдвига. В частности, если все точки изображения имеют один и тот же сдвиг (изображение сдвинуто целиком), то можно применить метод фазовой корреляции: вычислить преобразование Фурье для обоих изображений, найти свертку их фаз и по ней определить сдвиг (см. en.wikipedia.org/wiki/Phase_correlation). Также можно применять поблочное сравнение (block matching): находить сдвиг, минимизирующий норму разности изображений в окне. В чистом виде такой алгоритм будет работать долго и неустойчиво к поворотам и прочим искажениям. Английская википедия причисляет перечисленные алгоритмы к различным вариантам вычисления оптического потока, но мне это кажется не слишком корректным, так как эти алгоритмы могут быть применены и в других целях и не полностью решают данную задачу. Мы будем называть оптическим потоком методы, основанные на локальных характеристиках изображений (то, что в английской википедии называется differential methods).

Стандартный подход (метод Лукаса-Канаде)

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

Рассмотрим математическую модель оптического потока, считая, что у точки в результате смещения не изменилась интенсивность.

Пусть – интенсивность в некоторой точке (x, y) на первом изображении (т. е. в момент времени t). На втором изображении эта точка сдвинулась на (dx, dy), при этом прошло время dt, тогда – это мы разложили по Тейлору функцию интенсивности до первого члена (позже будет упомянуто, почему только до первого), здесь – частные производные по координатам и времени, то есть по сути – изменение яркости в точке (x, y) между двумя кадрами.

Мы считаем, что у точки сохранилась интенсивность, значит
Получаем одно уравнение с двумя неизвестными (dx и dy), значит его недостаточно для решения, то есть только на этом уравнении далеко не уедешь.

Самое простое решение проблемы – алгоритм Лукаса-Канаде. У нас же на изображении объекты размером больше 1 пикселя, значит, скорее всего, в окрестности текущей точки у других точек будут примерно такие же сдвиги. Поэтому мы возьмем окно вокруг этой точки и минимизируем (по МНК) в нем суммарную погрешность с весовыми коэффициентами, распределенными по Гауссу, то есть так, чтобы наибольший вес имели пиксели, ближе всего находящиеся к исследуемому. После простейших преобразований, получаем уже систему из 2 уравнений с 2 неизвестными:

Как известно, эта система имеет единственное решение не всегда (хотя и очень часто): если детерминант системы равен нулю, то решений либо нет, либо бесконечное число. Эта проблема известна как Aperture problem – неоднозначность сдвига при ограниченном поле зрения для периодических картинок. Она соответствует случаю, когда в поле зрения попадает фрагмент изображения, в котором присутствует некоторая цикличность; тут уж и человек не сможет однозначно определить, куда картинка сместилась. Проблема в том, что из-за шумов в таких неоднозначных ситуациях мы получим не нулевой детерминант, а очень маленький, который, скорее всего, приведет к очень большим значениям сдвига, особо не коррелирующим с действительностью. Так что на определенном этапе нужно просто проверять, не является ли детерминант системы достаточно маленьким, и, если что, не рассматривать такие точки или отмечать их как ошибочные.

Почему не работает?

Если мы остановимся на этом этапе и реализуем этот алгоритм, то он будет успешно работать. Но только если сдвиг между соседними изображениями будет очень маленький, порядка 1 пикселя, и то не всегда. (Для анализа качества генерировались синтетические последовательности с различным относительным сдвигом, причем этот сдвиг может выражаться нецелым числом пикселей, тогда результирующее изображение соответствующим образом интерполируется) Уже на сдвиге в 2 пикселя погрешность будет большая, а если 3 и более, то результат будет вообще неадекватным. В чем же дело?

Тут нам устроила подставу математика. Она привила нам ощущение, что все функции вокруг непрерывные и много раз дифференцируемые. И вообще нас в институте приучили приближение функции в окрестности точки записывать с помощью формулы Тейлора, и мы везде бездумно радостно пользуемся этим. А теперь задумаемся, какой физический смысл производных в данном месте? Мы хотим с их помощью определить изменение значения функции в конечной окрестности точки, а производная дает представление о бесконечно малой окрестности. Для расширения этой окрестности можно было бы добавить более высокий порядок производных в разложение Тейлора, но это приведет к нелинейностям в системе, от чего ее станет существенно сложнее решать, а преимущества будут сомнительны, тем более что на практике мы имеем дело не с непрерывными многократно дифференцируемыми функциями, а с вообще непонятно какими дискретными функциями. Поэтому логичнее будет искать функцию g(x), для которой в нашем дискретном случае как можно точнее выполняется f(x) + g(x) = f(x+1), f(x) + 2g(x) = f(x+2), f(x) — g(x) = f(x-1), и т. д. Таким образом, нам в этом случае нужна не производная, а некоторая линейная функция, наиболее близко лежащая к точкам исходной функции. Простые математические выкладки приводят к решению , где . Если мы строили производную по одной соседней точке с каждой стороны, то нам повезло: в этом случае формула совпадает с формулой приближенного вычисления производных: g(x) = (f(x+1) – f(x-1)) / 2. Что характерно, в OpenCV при вычислении оптического потока Лукаса-Канаде используется именно такая формула, к этому мы еще вернемся потом. А вот если взять больше точек, то формула уже становится совсем не похожа на классические разностные схемы для первой производной.

Очевидно, если мы строим эту функцию, например, по трем окрестным точкам слева и справа от исходной, то она никаким образом не зависит от точек, расположенных дальше, и, соответственно, при сдвиге более трех точек все равно у нас часто будут получаться неадекватные результаты. А еще, чем больше число точек, по которым мы строим эту функцию, тем больше среднее отклонение получаемой линии от используемых точек – опять же из-за того, что у нас не линейно меняющиеся изображения, а черт знает какие. На практике сдвиги более 2 пикселей уже дают неадекватно большую ошибку, сколько бы точек мы ни взяли.

Другим слабым местом алгоритма является то, что мы опять же имеем дело не с гладкими непрерывными функциями, а с произвольными, да еще и дискретными. Поэтому на некоторых фрагментах изображения интенсивность может «скакать» вообще без явных закономерностей, например на границах объектов, или из-за шумов. В этом случае никакая функция g(x) не сможет достаточно точно описать изменения изображения в окрестности точки. Чтобы с этим побороться (хотя бы частично), предлагается исходное изображение размазать, причем полезно будет его размазать достаточно сильно, то есть лучше применять даже не всеми любимый gaussian blur (усреднение с весовыми коэффициентами), а прямо таки box filter (равномерное усреднение по окну), да еще и несколько раз подряд. Гладкость изображения для нас сейчас важнее, чем детализация.

Тем не менее, эти меры так же не спасут нас от ограничения детектируемого сдвига в 2-3 пикселя. И кстати, в OpenCV 1.0 присутствовала такая реализация оптического потока, и работала она только в идеальных условиях на очень маленьких сдвигах.

Что же делать?

Итого, обычный Лукас-Канаде хорошо определяет маленькие сдвиги, такие, в рамках которых картинка похожа на свое линейное приближение. Чтобы с этим побороться, воспользуемся стандартным приемом CV – multi-scaling’ом: построим «пирамиду» изображений разного масштаба (почти всегда берется масштабирование в 2 раза по каждой оси, так проще считать) и пройдем по ним оптическим потоком от меньшего изображения к большему, тогда детектированный маленький сдвиг на маленьком изображении будет соответствовать большому сдвигу на большом изображении. На самом маленьком изображении мы обнаруживаем сдвиг не более 1-2 пикселей, а переходя от меньшего масштаба к большему, мы пользуемся результатом с предыдущего шага и уточняем значения сдвига. Собственно, в OpenCV его и реализует функция calcOptFlowPyrLK. Использование этого пирамидального алгоритма позволяет нам не заморачиваться вычислением линейной аппроксимации по многим точкам: проще взять больше уровней пирамиды, а на каждом уровне брать довольно грубое приближение этой функции. Поэтому в OpenCV и идет расчет всего по двум соседним точкам. И поэтому применительно к этой реализации алгоритма наши умозаключения про преимущество аппроксимирующей функции перед производной оказались бесполезными: для такого количества опорных точек производная и есть лучшая аппроксимирующая функция.

А какие еще бывают?

Этот алгоритм не является единственным вариантом вычисления оптического потока. В OpenCV кроме потока Лукаса-Канаде есть еще поток Farneback и SimpleFlow, также часто ссылаются на алгоритм Horn–Schunck.

Метод Horn–Schunck носит несколько более глобальный характер, чем метод Лукаса-Канаде. Он опирается на предположение о том, что на всем изображении оптический поток будет достаточно гладким. От того же самого уравнения предлагается перейти к функционалу , то есть добавить требование на отсутствие резкого изменения сдвигов с весовым коэффициентом α. Минимизация этого функционала приводит нас к системе из двух уравнений:

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

В данном алгоритме тоже предлагают использовать multi-scaling, причем рекомендуют масштабировать изображения не в 2 раза, а с коэффициентом 0.65

Этот алгоритм был реализован в первых версиях OpenCV, но в последствии от него отказались.

Farneback предложил аппроксимировать изменение интенсивности в окрестности с помощью квадратичной формы: I = xAx + bx + c с симметричной матрицей A (по сути, рассматривая разложение по Тейлору до первого члена, мы брали линейную аппроксимацию I = bx + c, то есть сейчас мы как раз решили повысить точность приближения) Если изображение сдвинулось в пределах этой окрестности, то , подставляем в квадратичное разложение, раскрываем скобки, получаем


.

Теперь мы можем вычислить значения A, b, c на обеих картинках, и тогда эта система станет избыточной относительно d (особенно смущает первое уравнение), и вообще d можно получить из второго уравнения: . Приходится прибегать к следующей аппроксимации: . Обозначим еще для простоты , Тогда получим просто .

Для компенсации шумов при вычислении, снова обратимся к тому предположению, что в окрестности исследуемой точки у всех точек более или менее одинаковый сдвиг. Поэтому опять же проинтегрируем погрешность по окну с гауссовскими весовыми коэффициентами w, и найдем вектор d, минимизирующий эту суммарную погрешность. Тогда мы получим оптимальное значение и соответствующую минимальную ошибку . То есть нам надо для каждой точки посчитать , усреднить по окну, инвертировать матрицу и получить результат. Соответственно эти произведения можно посчитать для всей картинки и использовать заранее рассчитанные значения для разных точек, то есть это как раз тот случай, когда имеет смысл считать dense поток.

Как обычно, у этого алгоритма есть некоторое количество модификаций и усовершенствований, в первую очередь позволяющих использовать известную априорную информацию – заданную начальную аппроксимацию потока – и, опять же, multi-scaling.

В основе метода SimpleFlow лежит следующая идея: если мы все равно не умеем определять сдвиг больше чем размер окна, по которому мы искали производные, то зачем вообще заморачиваться с вычислением производных? Давайте просто в окне найдем наиболее похожую точку! А для разрешения неоднозначностей и для компенсации шумов учтем, что поток непрерывный и в окрестности данной точки все точки имеют почти одинаковый сдвиг. А проблему с размером окна опять же решим за счет multi-scaling’а.

Более строго, алгоритм звучит так: для всех точек в окне находится функция «энергии», отвечающая (с обратной логарифмической зависимостью) за вероятность перехода исходной точки в эту точку: . Далее, считается свертка этой энергии с гауссовым окном и находятся значения (dx,dy), минимизирующие эту функцию. Чтобы получить субпиксельную точность, рассматривается малая окрестность найденной оптимальной точки (dx,dy) и в ней ищется пик функции энергии как пик параболоида. И, как было упомянуто выше, эта процедура выполняется для пирамиды масштабированных изображений. Еще у них в алгоритме предложены хитрые методы ускорения расчетов, но это уже кому интересно разберутся сами. Для нас же важно, что за счет этого данный алгоритм является (теоретически) достаточно быстрым при неплохой точности. И у него нет такой проблемы, как у предыдущих, что чем больше сдвиг, тем хуже он детектируется.

А если брать не интенсивность?

Выше было сказано, что соответствие между точками может определяться разными величинами, так почему же мы рассматриваем только интенсивность? А потому, что любую другую величину можно свести к ней: мы просто фильтруем изображения соответствующим фильтром и на вход описанных выше алгоритмов подаем отфильтрованные изображения. Соответственно, если вы хотите использовать оптический поток, то сначала подумайте, в ваших условиях какая характеристика изображения будет наиболее стабильной, и проведите соответствующую фильтрацию, чтобы на входе алгоритма оказалась не интенсивность, а эта характеристика.

Практика

Давайте опробуем на практике алгоритмы, которые нам предлагает OpenCV.

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

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

Классический Лукас-Канаде реализован с пирамидой в процедуре calcOpticalFlowPyrLK. Алгоритм рассчитывает sparse-поток, то есть для заданного набора точек на первом изображении оценивает их положение на втором. Входные параметры достаточно очевидны: два входных изображения, входной и выходной наборы точек, status – выходной вектор, показывающий, найдена ли успешно соответствующая точка, err – выходной вектор оцененных погрешностей соответствующих точек, WinSize – размер окна, по которому происходит гауссово усреднение, я брал 21х21 и работало хорошо, maxLevel – количество слоев в пирамиде минус один, т. е. номер последнего слоя, я брал 5, criteria – условие выхода из итеративного процесса определения сдвига (минимизация погрешности производится итеративно) – этот параметр я оставлял по умолчанию, flags – дополнительные флаги, например можно использовать начальное приближение потока или выбрать метод оценки погрешности, minEigThreshold – пороговое значение градиента, ниже которого матрица считается вырожденной, я оставлял по умолчанию. Начиная с OpenCV 2.4.1, при вычислении потока можно использовать заранее вычисленную пирамиду отмасштабированных изображений.

Результат работы – успешно и стабильно обнаруживаются как малые, так и большие сдвиги, устойчив к довольно большим шумам, время работы – порядка 10 мс для 400 точек c 5-слойной пирамидой (на core i7 950).

Кстати, этот алгоритм реализован так же на Gpu (CUDA), причем как dense, так и sparse версии.

Поток Farneback реализуется процедурой calcOpticalFlowFarneback, рассчитывается dense-поток, то есть сдвиг каждой точки. Параметры: входные изображения, выходной поток в формате двухканальной матрицы float’ов, pyr_scale определяет отношение масштабов между слоями пирамиды, levels – количество уровней в пирамиде, winsize – размер окна, по которому производится усреднение, iterations – количество итераций на каждом уровне, poly_n – размер полинома, по которому оцениваются значения A и b, poly_sigma – сигма гауссовского размытия при сглаживании производных, рекомендованные значения параметров указаны в мануале, flags – дополнительные флаги, например можно использовать начальное приближение потока или по-другому усреднять по окну.

Этот алгоритм куда менее стабилен (по моим наблюдениям), легче промахивается на довольно равномерных картинках (видимо, проблема в отсутствии фильтрации неудачных точек), плохо определяет большие сдвиги. У меня отрабатывал за 600 мс на изображении 512х512.

Поток SimpleFlow реализует процедура calcOpticalFlowSF (рассчитывается опять же dense поток), и у нее есть множество загадочных параметров без дефолтных значений, и вообще на данный момент на странице информация предоставлена весьма лаконично. Попробуем разобраться. Первые 3 – входные изображения и выходное двухканальное; layers – количество слоев в пирамиде, то есть сколько раз масштабируем исходное изображение; averaging_block_size – размер окна, в котором мы считали функцию энергии пикселей; max_flow – максимальный сдвиг, который мы хотим уметь определять на каждом шаге, по сути он определяется размером окна (хотя не совсем понятно, почему он int). На этом можно остановиться, а можно задать еще несколько параметров, смысл некоторых из них от меня ускользает.

На сайте предлагают посмотреть пример его использования, в котором он запускается с такими параметрами: calcOpticalFlowSF(frame1, frame2, flow, 3, 2, 4, 4.1, 25.5, 18, 55.0, 25.5, 0.35, 18, 55.0, 25.5, 10);

У меня алгоритм работает значительно медленнее других, порядка 9-12 секунд на картинку 512х512. Результат работы кажется более правдоподобным, чем Farneback, по крайней мере лучше определяется сдвиг на равномерных картинках, заметно лучше срабатывает с большими сдвигами.

Выводы

Если вы хотите использовать где-то оптический поток, сначала подумайте, нужен ли он вам: часто можно обойтись более простыми методами. Браться реализовывать поток самостоятельно стоит только несколько раз подумав: каждый алгоритм имеет множество хитростей, тонкостей и оптимизаций; что бы вы ни сделали, скорее всего, в OpenCV оно же работает лучше (естественно, при условии, что оно там есть). Тем более что они там вовсю используют логические и хардварные оптимизации типа использования SSE инструкций, многопоточность, возможности вычисления с CUDA или OpenCL и т. д. Если вам достаточно посчитать сдвиг некоторого набора точек (т. е. sparse поток), то можете смело использовать функцию calcOpticalFlowPyrLK, оно работает хорошо, надежно и достаточно быстро. Для вычисления dense-потока хорошо использовать функцию calcOpticalFlowSF, но она работает очень медленно. Если быстродействие критично, то calcOpticalFlowFarneback, но надо еще удостовериться, что результаты его работы вас устроят.

Источник