Сафронов А.И. (АУИ-511), Сидоренко В. Г. - профессор

СРЕДСТВА АНАЛИЗА КАЧЕСТВА ИСПОЛНЕНИЯ ПЛАНОВОГО ГРАФИКА ДВИЖЕНИЯ ПАССАЖИРСКИХ ПОЕЗДОВ МЕТРОПОЛИТЕНА

В настоящее время на Московском метрополитене функционирует широкий спектр средств автоматизации управления перевозочным процессом, разработанных на кафедре «Управление и информатика в технических системах» МИИТа. Одной из таких систем является автоматизированная система построения планового графика движения (АСППГД), которая является не только средством планирования перевозочного процесса (построения планового графика движения (ПГД)), но и контроля и анализа его исполнения (построения графика исполненного движения (ГИД)). ГИД представляет собой результат фактического движения поездов по линии. На сегодняшний день в системе функционирует только механизм визуального отображения ГИД, которое позволяет проводить визуальную оценку качества исполнения ПГД, которая не может быть лишена субъективизма. Данная работа посвящена вопросу автоматизации анализа качества исполнения ПГД.

На первой стадии разработки необходимо формализовать знания о ПГД и ГИД в одних и тех же терминах, к которым относятся понятия нитки графика, образа нитки графика, элемента расписания.

Синтез множеств ниток, элементов расписания, описывающих ГИД, проводится с использованием существующих и вновь создаваемых операций и процедур построения ПГД.

При этом важно учесть и отразить всевозможные маневровые передвижения, осуществляемые поездом:

- уход/выход в оборот/из оборота;
- уход/выход в/из депо;
- уход/выход в ночную расстановку/из ночной расстановки;
- начало движения с перегона;
- начало движения от станции.

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

Поезд движется по графику, если:

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

Основными показателями графика движения пассажирских поездов, принятыми на Московском метрополитене, являются:

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

В результате проведенных на кафедре «Управление и информатика в технических системах» МИИТа работ этот перечень был расширен:

- коэффициент реализации графика;
- коэффициент реализации заданных интервалов по прибытию;
- коэффициент реализации заданных интервалов по отправлению.

Авторами проведена формализация вновь введенных терминов в терминах формализации построения ПГД и ГИД.

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

Библиографическая ссылка:

Сафронов, А. И. Средства анализа качества исполнения планового графика движения пассажирских поездов метрополитена / А.И. Сафронов, В.Г. Сидоренко // Труды научно-практической конференции «Неделя науки-2009. Наука МИИТа – транспорту». – М.: МИИТ. – 2009. – C. II–73-II-74.

Сафронов А.И. (АУИ-511), Ковалёв М.В. (АУИ-511), Сидоренко В. Г. - профессор

ФОРМАЛИЗАЦИЯ ЗАДАЧ ОТОБРАЖЕНИЯ ИНФОРМАЦИИ В АВТОМАТИЗИРОВАННОЙ СИСТЕМЕ ПОСТРОЕНИЯ ПЛАНОВОГО ГРАФИКА ДВИЖЕНИЯ ПАССАЖИРСКИХ ПОЕЗДОВ МЕТРОПОЛИТЕНА (АСППГД)

Информация в АСППГД может представляться в графическом и текстовом виде.
Информация о движении маршрутов по линии метрополитена представляется в графическом виде в форме ПГД (плановый график движения) или ГО (график оборота). ПГД представляет собой множество образов ниток.
Процесс отображения образов ниток включает в себя следующие этапы:

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

Перечисленная выше информация может корректироваться путем выбора объекта на форме. Выбранный объект определяется точкой нажатия на левую кнопку манипулятора «мышь» или путем последовательного перемещения по ниткам с использованием элементов управления, размещенных на панели инструментов (перейти к предыдущей, следующей нитке или поезду, найти первую или последнюю нитку последовательности, найти нитку с заданным номером поезда). Далее на выбранной нитке определяется тип точки, над которой выполняется коррекция: перегон, станция, депо. Авторами разработана процедура коррекции времени хода по соединительным путям депо и времени стоянки на станции после выхода из депо.
В текстовом виде отображается информация о некоторых параметрах ниток (номер поезда, номер маршрута) и интегральных характеристиках графика, например: парность, эксплуатационные измерители, количество маршрутов, находящихся в депо в текущий момент времени и т.д. Эта информация формируется на базе анализа ниток планового графика.
Авторами разработан алгоритм определения количества маршрутов, находящихся в депо в текущий момент времени, который включает в себя следующие основные этапы:

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

Библиографическая ссылка:

Сафронов, А. И. Формализация задач отображения информации в автоматизированной системе построения планового графика движения пассажирских поездов метрополитена (АСППГД) / А.И. Сафронов, М.В. Ковалёв, В.Г. Сидоренко // Труды научно-практической конференции «Неделя науки-2009. Наука МИИТа – транспорту». – М.: МИИТ. – 2009. – C. II–49.

УДК 656.25-52:656.22.05:656.42
Ковалёв М.В., Сафронов А.И., Сидоренко В.Г.
Московский Государственный Университет Путей Сообщения (МИИТ)
Москва, Россия

СИСТЕМАТИЗАЦИЯ СПОСОБОВ ОТОБРАЖЕНИЯ ИНФОРМАЦИИ ПЛАНОВОГО ГРАФИКА ДВИЖЕНИЯ ПАССАЖИРСКИХ ПОЕЗДОВ МЕТРОПОЛИТЕНА

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

Московский метрополитен - обширное транспортное предприятие, в работу которого вовлечено большое количество человеческих и материальных ресурсов. Это связано со сложностью и неотложностью решаемых на предприятии задач. Автоматизация различных технологических процессов на Московском метрополитене позволяет облегчить работу специалистов различных служб метрополитена. В данной статье систематизированы и обобщены полученные в ходе создания и внедрения на Московском метрополитене автоматизированной системы построения планового графика движения пассажирских поездов метрополитена (далее, система) результаты работы кафедры «Управление и информатика в технических системах» Московского государственного университета путей сообщения (МИИТ). Одной из задач, стоящих перед разработчиками системы, в решении которой принимают участие авторы статьи, является организация вывода на экран и печать синтезированного графика в формате, принятом на Московском метрополитене. Ее актуальность не ослабевает, т.к. метрополитен развивается, и система обозначений также претерпевает изменения.
Плановый график (ПГ) полностью описывается тремя множествами: ниток графика, элементов расписания и ремонтов. Каждому из этих типов элементов соответствует свой образ в рамках графика движения или графика оборота подвижного состава.
Нитка графика описывает движение маршрута от момента выхода на главный путь до момента ухода с него с указанием маневровых передвижений в начале и конце движения по главному пути и содержит информацию о переходах маршрута с одной нитки графика на другую и порядке следования ниток графика по одному главному пути. Под образом нитки будем понимать объект, описывающий графическое отображение движения маршрута от момента выхода на главный путь до момента ухода с него с указанием маневровых передвижений в начале и конце движения по главному пути.
Рассмотрим решение задачи отображения маневровых передвижений в конце нитки. Классификация маневровых передвижений после окончания движения по главному пути приведена на рисунке 1. Концом нитки, фактически, является момент ухода поезда с линии, ухода на ночную расстановку или начала движения по следующей нитке.

Рисунок 1

С линий поезд может уходить в депо (в осмотр или на ночную расстановку) и на другую линию. Дальнейшая классификация сводится к таким нюансам, как уход поезда со станции или, непосредственно, с перегона. График движения поездов по другой линии, на которую уходят поезда, может отображаться на том же листе, что и основной, или на другом, тогда на текущем графике отображается только станция, которая связывает линии.
Концом нитки также может быть уход поезда на ночную расстановку в конце рабочего дня. Ночью поезд может находиться на том же главном пути; на другом главном пути (подразумевается уход на ночную расстановку после оборота); на станционном пути, связанном с главным путём, по которому происходило его движение; на станционном пути, связанном с главным путём противоположного направления (опять же подразумевается уход на ночную расстановку после оборота).
Существует множество способов отображения перехода маршрута от одной нитки к следующей. Выбор того или иного способа определяется следующими условиями: станция конечная или промежуточная; наличие более одного поезда на станции; организация зонного движения; наличие пункта осмотра на станционных путях линии; маршрут просто оборачивается или уходит на ночную расстановку. В случае кольцевой линии переход с одной нитки на другую на том же пути не сопровождается дополнительными маневровыми передвижениями, однако требуется обозначить место разрыва ниток при отображении графика кольцевого движения на бумаге. После нахождения на станционных путях маршрут может продолжить движение по тому же пути, по которому двигался и раньше, или выйти на другой путь. Перемещения между главными и станционными путями, так же, как и в случае с депо, могут осуществляться на станции или на перегоне.
Очевидно, что условные обозначения, применяемые на ПГ, должны позволять однозначно определять когда, куда и каким образом уходит поезд с линии. В состав возможностей автоматизированной системы входит решение этой задачи.
Для прорисовки того или иного варианта конца нитки графисту, работающему в системе, достаточно всего лишь выделить нитку и в контекстном меню, появляющемся по клику правой кнопкой мыши при нажатой клавише «Ctrl», выбрать необходимый вариант прорисовки. Именно выбор того или иного пункта меню задаёт дальнейшее движение по коду программы. Данный процесс разветвлён по множеству условий, определяемых приведенной выше классификацией. Выполнение операций по той или иной ветви, в целом, незначительно отличается друг от друга, но именно эти отличия и задают особенности отображения конца нитки графика. В некоторых случаях отображение маневровых передвижений требует создания еще одной нитки, например, при ночной расстановке, требующей переход с одного главного пути на другой. Все действия по отображению выбранного варианта маневровых передвижений выполняются автоматически.
Маневровые передвижения в начале движения по нитке симметричны рассмотренным ранее. Все описанные выше особенности распространяются и на начало нитки. В связи с этим, задача отображения начала движения по нитке решается аналогично рассмотренной задаче отображения конца движения по нитке.
Отдельно стоит рассмотреть вопросы прорисовки элементов расписания, т.е. отображения движения по главному пути. Особенностью решения этой задачи является то, что на сетке ПГ расположение горизонтальных линий, соответствующих станциям, определяется расстоянием между станциями в масштабе времени. Время хода между двумя станциями в разных направлениях может не совпадать. Поэтому сетка строится по усредненным данным для режимов ведения в часы с наименьшей нагрузкой (часы-непик). На многих линиях существуют разные режимы вождения для часов с наибольшей (часы-пик) и наименьшей нагрузкой (часы-непик). Особым случаем является ситуация движения первых поездов с увеличенным временем хода и резервных поездов после окончания пассажирского движения без остановок на станциях. В связи с изменением времени хода абсциссы точек пересечения ниток графика с уровнями, соответствующими промежуточным станциям линии, могут не совпадать с реальными временами отправления с этих станций. Движение поезда на сетке графика метрополитена изображается прямой линией (ниткой поезда); проекция этой линии на горизонтальную ось равна времени хода поезда по данному участку. Нитка графика отображается набором наклонных отрезков с одинаковым углом наклона (кроме, первых поездов с увеличенным временем хода) и набором горизонтальных отрезков, отображающих сверхнормативные стоянки; координаты начала и конца нитки определяются начальной и конечной станциями, временами отправления с начальной станции и прибытия на конечную станцию; угол наклона нитки графика определяется временем хода поезда без учета времени сверхнормативных стоянок; длина горизонтальных отрезков определяется длительностью соответствующих сверхнормативных стоянок. На метрополитене принят следующий формат отображения ниток: углы наклона отрезков нитки первых поездов рассчитываются отдельно для участка движения с увеличенным временем хода и для участка движения с графиковым временем хода. Нитки начинаются, заканчиваются и меняют угол наклона в точках, абсциссы которых совпадают с реальными временами отправления (прибытия) на соответствующих станциях. Нитки резервных поездов также начинаются и заканчиваются в точках, абсциссы которых совпадают с реальными временами отправления (прибытия) на соответствующие станции. Все остальные неполные нитки, т.е. те, которые начинаются или заканчиваются не на конечной станции, отображаются параллельно полным ниткам, идущим в том же режиме.
Одной из сервисных функций системы является отображение параметров синтезированного графика и текущего состояния объектов линии метрополитена. Параметрами ПГ являются рассчитанные для каждого размера движения заданная и фактическая парность, число поездов, отправившихся по первому или второму главным путям, число составов, необходимое для реализации заданной парности. В каждый момент времени графист должен знать, сколько составов находится в депо, сколько времени прошло с начала отстоя маршрута. Реализация этих функций требует выполнения дополнительных математических расчетов и реализации дополнительных средств визуализации информации.
К машинисту данные ПГ поступают в форме расписания. Расписание печатается на карточках определённого размера. Размеры эти строго определены для каждой линии и зависят от количества станций, располагающихся на линии. На карточках расписания также указывается информация о времени хода, интервале движения, впереди и сзади идущих поездах, маневровых передвижениях впереди идущего поезда и текущего маршрута. Эта информация получается автоматически на основании анализа множества ниток графика.
Выполненный авторами анализ способов отображения информации о ПГ показал, какую важную роль играет решение задачи отображения информации при создании системы, насколько она трудоемка и многогранна. Созданный разработчиками системы аппарат позволяет наращивать возможности системы и учитывать вновь возникающие требования заказчика.

Библиографическая ссылка:

Ковалёв, М. В. Систематизация способов отображения информации планового графика движения пассажирских поездов метрополитена / М.В. Ковалёв, А.И. Сафронов, В.Г. Сидоренко // «Инновационные технологии в автоматике, информатике и телекоммуникациях». Труды Международной конференции ученых транспортных вузов, инженерных работников и представителей академической науки. 9-10 октября. – Хабаровск: ДВГУПС. – 2008. – С. 244-248.

Сафронов А.И. (АУИ-411), Ковалёв М.В. (АУИ-411), Сидоренко В. Г. - профессор

ОРГАНИЗАЦИЯ ИНТЕРФЕЙСА АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ ПОСТРОЕНИЯ ПЛАНОВОГО ГРАФИКА ДВИЖЕНИЯ ПОЕЗДОВ МЕТРОПОЛИТЕНА

На протяжении многих лет коллектив НИЛ АУДП МИИТа проводит разработки по созданию системы, способной автоматизировать процесс составления планового графика движения поездов. Данная система на сегодняшний день широко используется в Московском метрополитене. В процессе использования системы, как программного продукта, появляются новые задачи, решение которых нуждается в автоматизации. Они связаны не только с изменением заложенных алгоритмов решения комбинаторных задач, но и с организацией общения графиста с системой.
Если рассматривать автоматизированный процесс составления планового графика движения поездов как взаимодействие двух систем - ЭВМ и графиста, то для их общения необходима пограничная среда, ясная и понятная обоим. Такой пограничной средой является интерфейс. Его улучшению и посвящена наша работа.
В ходе работы модернизации подверглись два документа: график движения (ГД) и график оборота (ГО) подвижного состава.
Основными типами объектов, задействованных в составлении ГД и ГО, являются маршрут, нитка графика, образ нитки. Под образом нитки будем понимать объект, описывающий графическое отображение движения маршрута от момента выхода на главный путь до момента ухода с него с указанием маневровых передвижений в начале и конце движения по главному пути.
В работе решались следующие задачи:
- масштабирование ГО в зависимости от разрешающей способности экрана;
- подготовка среды для построения продленных ГД;
- возможность вывода на печать продленных ГО и ГД с большим числом маршрутов;
- изменение параметров движения маршрутов в депо и из депо.
В результате работы программно реализованы следующие процедуры, связанные с решением перечисленных задач:
- автоматического выбора масштаба отображения ГО, позволяющего полностью использовать разрешающую способность экрана по ширине;
- увеличения размерности массива размеров движения и записи его в базу данных (БД), а также количества листов ГД в зависимости от времени отправления последнего пассажирского поезда и времени снятия напряжения с контактного рельса;
- настройки параметров вывода на экран ГО в зависимости от числа маршрутов, приписанных к депо;
- идентификации выбранной для редактирования точки линии связи нитки с депо;
- редактирования времён начала движения в/из депо и продолжительности этого движения, а также соответствующего этому изменения образа нитки.
При отображении движения состава в/из депо возможны различные варианты: время отправления в/из депо может совпадать со временем прибытия состава на конечную станцию, а может учитывать время стоянки для высадки/посадки пассажиров. Время движения состава в/из депо может варьироваться в зависимости от того, по какому станционному пути оно выполняется или от требований к взаимному расположению составов на этих путях. Эти данные необходимо сохранять в БД индивидуально для каждой нитки, если они отличаются от стандартных.
Благодаря внесённым в автоматизированную систему построения планового графика движения пассажирских поездов по линии метрополитена улучшениям, стали доступны новые возможности построения и отображения ГД и ГО, которые уже сегодня активно используются графистами Московского метрополитена и облегчают их работу.

Библиографическая ссылка:

Сафронов, А. И. Организация интерфейса автоматизированной системы построения планового графика движения поездов метрополитена / А.И. Сафронов, М.В. Ковалёв, В.Г. Сидоренко // Труды научно-практической конференции «Неделя науки-2008. Наука МИИТа – транспорту». – М.: МИИТ. – 2008. – C. VII–51–VII–52.

"ДАЛЕЕ ТЕКСТ"

Что же, в каком-то смысле в этом году я променял блог на иную форму самиздата. И прошло всё в этом отношении, на мой взгляд, эффективно.

Встречайте на сайте библиотеки РУТ (МИИТ):

1. СОСТАВЛЕНИЕ ОТЧЁТНОЙ ДОКУМЕНТАЦИИ ПО РЕШЁННЫМ
ЗАДАЧАМ АЛГОРИТМИЗАЦИИ И ПРОГРАММИРОВАНИЯ

2. ПОЛУЧЕНИЕ ПЕРВИЧНЫХ ПРОФЕССИОНАЛЬНЫХ
УМЕНИЙ И НАВЫКОВ НАУЧНО-ИССЛЕДОВАТЕЛЬСКОЙ ДЕЯТЕЛЬНОСТИ

3. ДИСПЕТЧЕРСКАЯ ЦЕНТРАЛИЗАЦИЯ МОСКОВСКОГО МЕТРОПОЛИТЕНА

4. ПРОЕКТИРОВАНИЕ ТИПОВОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ УПРАВЛЕНИЯ С ИСПОЛЬЗОВАНИЕМ ТЕХНОЛОГИИ WEB-ПРОГРАММИРОВАНИЯ НА БАЗЕ ФРЕЙМВОРКА VUE.JS

Годовой план изданий учебно-методической литературы выполнен на все 100%.

Серия сообщений "Активная позиция":
Часть 1 - ВЗАИМОДЕЙСТВИЕ СО СТРУКТУРАМИ ПРАВИТЕЛЬСТВА
Часть 2 - ОБРАЩЕНИЕ К ПРАВИТЕЛЬСТВУ №2
...
Часть 19 - ЛЕКЦИЯ -МЕТРОПОЛИТЕН. В ЦЕНТРЕ ВНИМАНИЯ-. АНОНС
Часть 20 - ПРО ТРОТУАР МЕЖ РЯБИНОВОЙ И НИКУЛИНСКОЙ
Часть 21 - УЧЕБНО-МЕТОДИЧЕСКОЕ
Часть 22 - ДЕНЬ БЕЗ ТРАНСПОРТА 52: ПОСТ-COVIDАЛИПСИС. АНОНС

Серия сообщений "Vue.js":
Часть 1 - ПЛАГИН -xBASEVIEW- ДЛЯ -TOTAL COMMANDER-. ВВЕДЕНИЕ
Часть 2 - JSON TEST
...
Часть 4 - АВТОМАТИЗИРУЕМ СОСТАВЛЕНИЕ СПИСКОВ С VUE.JS. ПРИМЕРЫ
Часть 5 - ДЕЛАЕМ ПРОГРАММИРОВАНИЕ СО VUE.JS УДОБНЕЕ И ПРИЯТНЕЕ
Часть 6 - УЧЕБНО-МЕТОДИЧЕСКОЕ

Как и было заявлено ранее, для демонстрации работы CASE-структуры откажемся от операндов "Операнд 1" и "Операнд 2", чтобы сделать акцент на логике работы виртуального прибора (см. рисунок).

Пример заготовки на блок-диаграмме фрагмента "Умного калькулятора", не требующего участия каких-либо операндов

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

- либо кнопка "Один" нажата, а кнопки "Два" и "Три" не нажаты,
- либо кнопка "Два" нажата, а кнопки "Один" и "Три" не нажаты,
- либо кнопка "Три" нажата, а кнопки "Один" и "Два" не нажаты.

Построим схему на блок-диаграмме в соответствии со сформулированной выше логикой. Начнём с первого условия: сигналы "Два" и "Три" логически перемножаются и инвертируются функцией объединённой арифметики. Полученный результат логически умножается на сигнал "Один" (см. рисунок).

Составление логики для нажатой кнопки "Один" и не нажатых кнопок "Два" и "Три"

По аналогии строится схема для второго условия: сигналы "Один" и "Три" логически перемножаются и инвертируются функцией объединённой арифметики. Полученный результат логически умножается на сигнал "Два" (см. рисунок).

Добавление логики для нажатой кнопки "Два" и не нажатых кнопок "Один" и "Три"

Схема дополняется учётом третьего условия (см. рисунок).

Добавление логики для нажатой кнопки "Три" и не нажатых кнопок "Один" и "Два"

Решение задачи контроля нажатия одной единственной кнопки из трёх при составлении данной логической цепочки - это тот редкий случай, когда уместно применение операции исключающего ИЛИ ("XOR"). Это трудно принять с первого прочтения, поскольку само по себе в рассуждениях напрашивается обыкновенное логическое сложение, но это не так. Для доказательства составим таблицу истинности по логическому сложению (Таблица 1) и таблицу истинности для исключающего ИЛИ (Таблица 2).

Таблица 1 – Истинность объединения трёх операндов по логике ИЛИ

Таблица 2 – Истинность объединения трёх операндов по логике исключающего ИЛИ

Хорошо видно, что объединение по ИЛИ – это наличие истины в ХОТЯ БЫ ОДНОМ из трёх сигналов. Иначе: если хотя бы один элемент из множества отвечает истиной, то всё логическое выражение отвечает истиной. Такая логика для работы с одной единственной нажатой кнопкой не подходит. Логика исключающего ИЛИ утверждает следующее: ТОЛЬКО ОДИН из элементов множества должен ответить истиной, тогда и всё выражение ответит истиной.

Объединение ранее сформулированных условий по исключающему ИЛИ посредством использования блока объединённой арифметики National Insruments LabView представлено на следующем рисунке. Вместе с тем для тестирования виртуального прибора в блок истинного результата CASE-структуры по итогам составления расчётной схемы для всего логического выражения устанавливается константа "плюс бесконечность".

Объединение условий по исключающему ИЛИ ("XOR"). Проверка работоспособности составленной схемы: если условие выполняется – выводится "бесконечность" ("Inf")

В блоке ложного результата CASE-структуры (см. следующий рисунок) для всего логического выражения выставляется константа "не числового значения" ("NaN"). Для создания константы не числового значения на блок-диаграмме размещается обыкновенная целочисленная константа и в ней вручную записывается с клавиатуры "NaN" при строгом учёте верхнего и нижнего регистра символов (две заглавных "N" объединяются между собой строчной "a").

Проверка работоспособности составленной схемы: если условие не выполняется – выводится "не числовое значение" ("NaN")

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

Передача сформированного CASE-структурой результата на интерфейсный элемент, выводящий ответ

Запуск виртуального прибора при всех не нажатых кнопках даёт в результате не числовое значение – произошло попадание в блок ложного результата. Согласно составленной ранее таблице истинности так и должно быть.

Проверка работоспособности составленной логики: ничего не нажато – результат отрицательный

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

Проверка работоспособности составленной логики: нажаты все три кнопки сразу – результат отрицательный

Запуск с нажатыми кнопками "Один" и "Три" – шестая строчка таблицы истинности (не считая заголовка). В ответе ложный результат, но так и должно быть.

Проверка работоспособности составленной логики: нажаты сразу две кнопки – результат отрицательный

Запуск с нажатыми кнопками "Один" и "Два" – седьмая строчка таблицы истинности (не считая заголовка). В ответе ложный результат. Адекватно.

Проверка работоспособности составленной логики: нажаты сразу две другие кнопки – результат отрицательный

Наконец, встречается только "Один" – это пятая строчка таблицы. В ответе "плюс бесконечность" вместо "не числового значения" – попали в блок истинного результата. Тоже адекватно.

Проверка работоспособности составленной логики: нажата только одна кнопка – результат положительный

После нехитрого тестирования продолжим развитие кода заготовки виртуального прибора "Умный калькулятор" в направлении желаемого результата. В блоке ложного результата контрольной (внешней) CASE-структуры оставляем константу не числового значения, а в блоке истинного результата размещаем ещё одну, вложенную CASE-структуру. На логический вход вложенной CASE-структуры подаём ветвь логики, отвечающей за нажатие на кнопку "Один" и не нажатие на кнопки "Два" и "Три". Итого, если нажата кнопка "Один", то в блоке истинного результата должна зарождаться численная константа, равная "1". Но если "Один" не нажата, то остаётся ещё два возможных варианта, которые необходимо проверить (либо нажата кнопка "Два", либо нажата кнопка "Три"). Это ещё одна вложенная CASE-структура.

Развитие структуры программы: в случае, если нажата только одна кнопка, и эта кнопка – "Один", то должно выводиться в качестве ответа целочисленное значение, равное "1"

На логический вход новой CASE-структуры подаём проверку условия нажатия на кнопку "Два". Если, действительно, нажата кнопка "Два", то должна генерироваться константа, равная "2".

Развитие структуры программы: в случае, если нажата только одна кнопка, и эта кнопка не "Один", а "Два" – должно выводиться в качестве ответа целочисленное значение, равное "2"

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

Развитие структуры программы: в случае, если нажата только одна кнопка, и эта кнопка не "Один" и не "Два", а заключительный вариант – нажата кнопка "Три" и, соответственно, должно выводиться в качестве ответа целочисленное значение, равное "3"

Нижеследующие иллюстрации демонстрируют адекватность работы созданного фрагмента виртуального прибора "Умный калькулятор" с учётом ранее проведенных тестов по защите от одновременного выбора нескольких операций.

Проверка работоспособности программного обеспечения: нажата кнопка "Один" и в качестве ответа выдаётся значение, равное "1"

Проверка работоспособности программного обеспечения: нажата кнопка "Два" и в качестве ответа выдаётся значение, равное "2"

Проверка работоспособности программного обеспечения: нажата кнопка "Три" и в качестве ответа выдаётся значение, равное "3"

Серия сообщений "LabView":
Часть 1 - LABVIEW. НЕХИТРЫЕ ЗАДАЧКИ ПО ПРОГРАММИРОВАНИЮ. УГАДАЙ ЧИСЛО
Часть 2 - LABVIEW. ОЗНАКОМЛЕНИЕ С ПОЛЬЗОВАТЕЛЬСКИМ ИНТЕРФЕЙСОМ
...
Часть 11 - LABVIEW. ИСПОЛЬЗОВАНИЕ БЛОКА ОБЪЕДИНЁННОЙ АРИФМЕТИКИ
Часть 12 - LABVIEW. ЗАГОТОВКА GUI И КОДА ВП -УМНЫЙ КАЛЬКУЛЯТОР-
Часть 13 - LABVIEW. ИСПОЛЬЗОВАНИЕ CASE-СТРУКТУРЫ В ЛОГИЧЕСКОМ РЕЖИМЕ

В качестве первого приближения к созданию виртуального прибора (ВП) "Умный калькулятор" рассмотрим один из его возможных графических пользовательских интерфейсов (ГПИ / GUI). Для понимания принципов наращивания (масштабирования) структуры виртуального прибора "Умный калькулятор" достаточно рассмотреть всего три операции. Каждой операции ставится в соответствие логический контроллер – кнопка. Так на передней панели должны быть размещены три кнопки, которые назовём слева направо "Один", "Два" и "Три", соответственно. В таком случае подразумевается вывод на численный индикатор "Ответ" по нажатии "своей", заранее определённой кнопки, целочисленной константы: либо "1", либо "2", либо "3", соответственно.

Стоит отметить, что для большинства вариантов данной работы требуется использование операндов для выполнения над ними определённых операций. Под каждый операнд выделяется свой собственный численный контроллер. Заготовка интерфейса, представленная на следующем рисунке, содержит все вышеуказанные элементы, однако, в рассматриваемом примере "Операнд 1" и "Операнд 2" использованы не будут.

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

При таком наборе интерфейсных элементов управления блок-диаграмма будет содержать в себе те же компоненты, что представлены на следующем рисунке. Помимо них к заготовке добавлена CASE-структура. Заметим, что для большей компактности размещения элементов на блок-диаграмме при использовании инструмента позиционирования / изменения размера / выбора ("Position / Size / Select") наименования этих элементов размещены слева от них.

Заготовка блок-диаграммы для последующей настройки рассматриваемого примера

Итого в заготовке использованы элементы из следующих функциональных разделов:

- численные функции;
- логические функции;
- структуры.

Рассмотрение численных и логических функций уже затрагивалось в более ранних работах, связанных с "National Instruments LabView", а вот структуры ранее не использовались. Рассмотрим их расположение в перечне функций, доступных для размещения на блок-диаграмме (см. рисунок ниже).

Маркировка раздела структур в перечне функций, размещаемых на блок-диаграмме

Вход в раздел структур сопровождается выводом на экран окна, содержащего все существующие в "National Instruments LabView" структуры (их не много), которые при чтении слева направо следующие (см. рисунок далее):

- структура последовательности ("Sequence Structure");
- CASE-структура ("Case Structure");
- структура цикла "For" ("For Loop");
- структура цикла "While" ("While Loop");
- узел-формула ("Formula Node");
- структура событий ("Event Structure");
- глобальная переменная ("Global Variable");
- локальная переменная ("Local Variable").

Содержимое раздела структур блок-диаграммы с маркировкой CASE-структуры ("Case Structure")

CASE-структура может быть использована в логическом режиме (к знаку вопроса слева подключается связь логического типа), в таком случае её работа аналогична работе условного оператора. Также CASE-структура может быть использована в численном режиме (к знаку вопроса слева подключается связь целочисленного типа), и в таком случае структура работает как оператор переключения ("switch" на языке "Microsoft Visual C#").

Серия сообщений "LabView":
Часть 1 - LABVIEW. НЕХИТРЫЕ ЗАДАЧКИ ПО ПРОГРАММИРОВАНИЮ. УГАДАЙ ЧИСЛО
Часть 2 - LABVIEW. ОЗНАКОМЛЕНИЕ С ПОЛЬЗОВАТЕЛЬСКИМ ИНТЕРФЕЙСОМ
...
Часть 10 - LABVIEW. СТАНДАРТНЫЕ МАТЕМАТИЧЕСКИЕ ФУНКЦИИ И КОНСТАНТЫ
Часть 11 - LABVIEW. ИСПОЛЬЗОВАНИЕ БЛОКА ОБЪЕДИНЁННОЙ АРИФМЕТИКИ
Часть 12 - LABVIEW. ЗАГОТОВКА GUI И КОДА ВП -УМНЫЙ КАЛЬКУЛЯТОР-
Часть 13 - LABVIEW. ИСПОЛЬЗОВАНИЕ CASE-СТРУКТУРЫ В ЛОГИЧЕСКОМ РЕЖИМЕ

Объединённая арифметика - функция, относящаяся одновременно к двум разделам: числовому и логическому. Функция объединяет в себе следующие операции: сложения, умножения, логического сложения ("ИЛИ"), логического умножения ("И"), исключающего "ИЛИ". На рисунке далее показано расположение объединённой арифметики в разделе численных функций, размещаемых на блок-диаграмме.

Место расположения функции объединённой арифметики ("Compound Arithmetic") в разделе численных ("Numeric") функций, размещаемых на блок-диаграмме

При размещении объединённой арифметики на блок-диаграмме по умолчанию доступно только два входа, а также выбрана операция сложения. Для изменения количества входов необходимо выбрать среди инструментов элемент позиционирования / изменения размерности / выбора ("Position / Size / Select") и, ухватившись за нижнюю границу размещённой на блок-диаграмме функции, вытянуть её вниз на нужное количество входов. Для изменения выполняемой операции функцией объединённой арифметики необходимо вызвать контекстное меню этой функции нажатием на неё правой кнопкой мыши и далее в пункте изменения режима ("Change Mode") выбрать нужную операцию. В рамках решаемой задачи объединённая арифметика используется в режиме логического умножения ("AND"). Смена режима объединённой арифметики показана на следующем рисунке.

Замена операции в рамках функции объединённой арифметики с численного сложения "+" ("Add") на логическое умножение "И" ("AND")

С целью сокращения количества применяемых логических элементов на блок-диаграмме можно воспользоваться одной из полезных настроек функции объединённой арифметики. В контекстном меню функции объединённой арифметики присутствует возможность инвертирования ("Invert") полученного результата. Так, например, в решаемой задаче может быть эффективно использована операция отрицания логического умножения ("И-НЕ"). Такая операция доступна посредством размещения на блок-диаграмме одного единственного, но особым образом настроенного блока функции объединённой арифметики. Настройка инверсии логического умножения представлена на следующем рисунке.

Изменение режима применяемой операции логического умножения с прямой "И" на инверсную "И-НЕ" ("Invert AND")

По итогам изучения основ настройки функции объединённой арифметики, а также численных и логических элементов, входящих в состав пакета прикладных программ National Instruments LabView, можно переходить непосредственно к созданию заготовки для виртуального прибора "Умный калькулятор".

Серия сообщений "LabView":
Часть 1 - LABVIEW. НЕХИТРЫЕ ЗАДАЧКИ ПО ПРОГРАММИРОВАНИЮ. УГАДАЙ ЧИСЛО
Часть 2 - LABVIEW. ОЗНАКОМЛЕНИЕ С ПОЛЬЗОВАТЕЛЬСКИМ ИНТЕРФЕЙСОМ
...
Часть 9 - LABVIEW. ПРИМЕР НАСТРОЙКИ ЗАДАЮЩЕГО ЭЛЕМЕНТА
Часть 10 - LABVIEW. СТАНДАРТНЫЕ МАТЕМАТИЧЕСКИЕ ФУНКЦИИ И КОНСТАНТЫ
Часть 11 - LABVIEW. ИСПОЛЬЗОВАНИЕ БЛОКА ОБЪЕДИНЁННОЙ АРИФМЕТИКИ
Часть 12 - LABVIEW. ЗАГОТОВКА GUI И КОДА ВП -УМНЫЙ КАЛЬКУЛЯТОР-
Часть 13 - LABVIEW. ИСПОЛЬЗОВАНИЕ CASE-СТРУКТУРЫ В ЛОГИЧЕСКОМ РЕЖИМЕ

Раздел числовых элементов содержит следующие графические функции, подразделы и константы, изображённые на рисунке, представленном ниже (чтение ведётся слева направо, сверху вниз):

- операция сложения ("Add");
- операция вычитания ("Subtract");
- операция умножения ("Multiply");
- операция деления ("Divide");
- операции целочисленного деления и получения остатка от деления ("Quotient & Remainder");
- подраздел конвертации ("Conversion");
- операция инкрементирования / добавления единицы ("Increment");
- операция декрементирования / вычитания единицы ("Decrement");
- операция суммирования элементов массива ("Add Array Elements");
- операция перемножения элементов массива ("Multiply Array Elements");
- элемент, объединяющий арифметические операции ("Compound Arithmetic");
- подраздел тригонометрии ("Trigonometric");
- операция взятия абсолютной величины / модуля ("Absolute Value");
- операция математического округления до ближайшего целого ("Round To Nearest");
- операция округления в меньшую сторону ("Round To -Infinity");
- операция округления в большую сторону ("Round To +Infinity");
- операция выдачи реализации псевдослучайной величины ("Random Number (0-1)");
- подраздел логарифмов ("Logarithmic");
- операция взятия квадратного корня ("Square Root");
- операция инверсии / взятия значения с обратным знаком ("Negate");
- операция масштабирования по степени двойки / умножение на "2" в степени "N" ("Scale By Power Of 2");
- операция сигнум (определения знака): пришло любое положительное – в ответе "1", пришло любое отрицательное – в ответе "-1", пришёл ноль – в ответе "0" ("Sign");
- операция обращения / деления единицы на заданное значение ("Reciprocal");
- подраздел операций над комплексными числами ("Complex");
- численная константа ("Numeric Constant");
- перечислимая константа ("Enum Constant");
- константа списка значений ("Ring Constant");
- узел математических выражений ("Expression Node");
- подраздел дополнительных констант ("Additional Numeric Constants").

Раздел численных ("Numeric") функций на блок-диаграмме

Далее рассмотрен подраздел тригонометрических функций (см. рисунок, представленный ниже):

- синус ("Sine");
- косинус ("Cosine");
- тангенс ("Tangent");
- арксинус ("Inverse Sine");
- арккосинус ("Inverse Cosine");
- арктангенс ("Inverse Tangent");
- гиперболический синус ("Hyperbolic Sine");
- гиперболический косинус ("Hyperbolic Cosine");
- гиперболический тангенс ("Hyperbolic Tangent");
- гиперболический арксинус ("Inverse Hyperbolic Sine");
- гиперболический арккосинус ("Inverse Hyperbolic Cosine");
- гиперболический арктангенс ("Inverse Hyperbolic Tangent");
- косеканс ("Cosecant");
- секанс ("Secant");
- котангенс ("Cotangent");
- объединённый блок синуса и косинуса ("Sine & Cosine");
- арктангенс двух аргументов ("Inverse Tangent (2 Input)");
- функция отсчётов ("Sinc").

Подраздел тригонометрических ("Trigonometric") функций раздела численных ("Numeric") функций на блок-диаграмме

Далее рассмотрен подраздел логарифмических функций (см. рисунок, представленный ниже):

- экспонента ("Exponential");
- степень десяти ("Power Of 10");
- степень двойки ("Power Of 2");
- возведение "X" в степень "Y" ("Power Of X");
- экспонента, проходящая через начало координат ("Exponential (Arg) – 1");
- натуральный логарифм ("Natural Logarithm");
- логарифм по основанию десяти ("Logarithm Base 10");
- логарифм по основанию двойки ("Logarithm Base 2");
- логарифм по основанию "X" ("Logarithm Base X");
- натуральный логарифм, проходящий через начало координат ("Natural Logarithm (Arg + 1)").

Подраздел логарифмических ("Logarithmic") функций раздела численных ("Numeric") функций на блок-диаграмме

Далее рассмотрен подраздел дополнительных численных констант (см. рисунок, представленный ниже):

- цветовая константа ("Color Box Constant");
- символьная константа списка значений для интерфейсного элемента "список" ("Listbox Symbol Ring Constant");
- константа списка ошибок ("Error Ring Constant");
- Пифагорова константа ("Pi");
- Пифагорова константа, умноженная на два ("Pi Multiplied By 2");
- Пифагорова константа, делённая на два ("Pi Divided By 2");
- обращённая Пифагорова константа ("Reciprocal Of Pi");
- натуральный логарифм Пифагоровой константы ("Natural Logarithm Of Pi");
- минус бесконечность ("Negative Infinity");
- основание натурального логарифма ("Natural Logarithm Base");
- обращённое основание натурального логарифма ("Reciprocal Of e");
- логарифм экспоненты по основанию десяти ("Base 10 Logarithm Of e");
- натуральный логарифм десяти ("Natural Logarithm Of 10");
- натуральный логарифм двойки ("Natural Logarithm Of 2");
- плюс бесконечность ("Positive Infinity");
- постоянная Планка ("Planck Constant (J/Hz)");
- элементарный заряд ("Elementary Charge (C)");
- скорость света в вакууме ("Speed Of Light In Vacuum (m/sec)");
- гравитационная постоянная ("Gravitational Constant (N m2/kg2)");
- постоянная Авогадро ("Avogadro Constant (1/mol)");
- Постоянная Ридберга ("Rydberg Constant (/m)");
- молярная газовая постоянная ("Molar Gas Constant (J / (mol K))").

Подраздел дополнительных численных констант ("Additional Numeric Constants") раздела численных ("Numeric") функций на блок-диаграмме

Серия сообщений "LabView":
Часть 1 - LABVIEW. НЕХИТРЫЕ ЗАДАЧКИ ПО ПРОГРАММИРОВАНИЮ. УГАДАЙ ЧИСЛО
Часть 2 - LABVIEW. ОЗНАКОМЛЕНИЕ С ПОЛЬЗОВАТЕЛЬСКИМ ИНТЕРФЕЙСОМ
...
Часть 8 - LABVIEW. ПРИМЕР ВЫРАВНИВАНИЯ ШКАЛ ТЕРМОМЕТРОВ ПО УРОВНЮ
Часть 9 - LABVIEW. ПРИМЕР НАСТРОЙКИ ЗАДАЮЩЕГО ЭЛЕМЕНТА
Часть 10 - LABVIEW. СТАНДАРТНЫЕ МАТЕМАТИЧЕСКИЕ ФУНКЦИИ И КОНСТАНТЫ
Часть 11 - LABVIEW. ИСПОЛЬЗОВАНИЕ БЛОКА ОБЪЕДИНЁННОЙ АРИФМЕТИКИ
Часть 12 - LABVIEW. ЗАГОТОВКА GUI И КОДА ВП -УМНЫЙ КАЛЬКУЛЯТОР-
Часть 13 - LABVIEW. ИСПОЛЬЗОВАНИЕ CASE-СТРУКТУРЫ В ЛОГИЧЕСКОМ РЕЖИМЕ

Эта часть руководства посвящена постобработке в "Adobe Photoshop CS 6" получившегося в "Autopano Giga 4.2" планетоида. Ставится задача устранить тень фотографа и отсутствие кадра надира (да и зенита, в частности).

Откроем получившееся в "Autopano Giga" изображение через "Adobe Photoshop" и выберем инструмент "Волшебная палочка" (Рисунок 1). Уверен, что любого напрягает то чёрное пятно, которое светится прямо по центру изображения. Выделим объект щелчком мыши в любом фрагменте пятна. После этого пятно будет обрамлено в точности по границам (Рисунок 2). И, естественно, всё ненавистное нужно как можно скорее удалить, нажав на "Delete".

Стоит отметить, что раньше я работал в "Photoshop CS2" и вслед за нажатием удаления моментально выполнялась операция заливки фона указанным фоновым цветом. Ныне в "Photoshop CS6" жизнь существенно изменилась и за удалением следует диалог с пользователем. Но это даже удобно, поскольку можно выбрать нужный режим: от простой заливки цветом фона отказывается, выбираем "С учётом содержимого" (Рисунок 3). Результат, скорее, приятно порадует (Рисунок 4). В рассматриваемом примере получилось почти то, что нужно.

Теперь напрягает лишь ореол бывшей тени фотографа. Вот эту область ореола нужно выделить и не важно в каком режиме это будет сделано, хоть "Лассо", хоть сразу в режиме "Заплатка" (Рисунок 5), который и надо использовать для этого случая. В то время, когда фрагмент выделен (Рисунок 6), в него необходимо разместить курсор мыши и он изменится, подсказывая, что область можно тянуть.

Перетягивается область куда-то для того, чтобы указать программе шаблон, который будет адаптивно интегрироваться в исходную область изображения (Рисунок 7). То есть это получается не совсем копия указанного фрагмента, а нечто среднее, причём, не усреднённое, не размытое, а именно среднее. Не могу представить, как работает данный свёрточный алгоритм фильтрации в точности, но что-то мне подсказывает, что устраняется монотонная составляющая определённого цвета (или цветов), на её место подставляется копия указанного фрагмента и результат сглаживается / смешивается / блендится. Потому я и сказал, что интегрируется адаптивно, то есть некоторый "ум" у функции, всё же, есть и работать с ней крайне приятно.

В результате получается картинка, на которую не стыдно смотреть (Рисунок 8), но ещё пока стыдно кому-то показать. Стыдно всё ещё смотреть на отсутствие кадра зенита. Впрочем, эту область не жалко обрезать. И, может быть, при вращении исходника окажется, что изображение смотрится в разы лучше, чем предложенное "авторское" видение / представление программы "Autopano Giga", с которым, замечу, на предыдущем этапе мы даже спорить не стали.

То есть я настоятельно рекомендую планетоид в "Photoshop" повращать (эта функция в "Photoshop" выполняется в разы быстрее, чем в "Autopano"). Процедура вращения планетоида доставляет массу эстетического удовольствия. Кстати, может найтись несколько точек с "Вау!"-эффектом. Но не стоит забывать, что экран мобильного телефона, к примеру, можно вращать не виртуально, а физически, потому для изображения стоит, всё же, остановиться на каком-то одном угле поворота, а вот если кому-то показывать, то посоветовать повернуть экран на какой-то угол и сказать на словах, что так тоже очень круто.

Да, не стоит забывать, что планетоиды - это уже арт / художество / креатив, полученный в результате обработки фотографий, поэтому двух одинаковых планетоидов у разных авторов точно не получится. Это искусство. Это как молния в одну точку два раза подряд... Нет, бьёт, конечно, случается, но очень-очень-очень-очень-очень редко, с точки зрения теории вероятностей - никогда. Поэтому творим!

В качестве некоторой массовой критики. Я искренне не понимаю, почему так мало людей заморачивается на создании планетоидов в настоящее время. Это же столь необычно и, ещё раз, подчёркиваю, креативно. На сегодняшний день дроны-беспилотники умеют автоматом сшивать сфероиды, есть специальные палки-штативы для съёмки сфероида 360 degree stick и прочие инструменты... Правда, я на результаты смотрю, и они все для меня далеки от того результата, которые достигается при ручной и полуавтоматизированной сборке. Не то это.

Так что не ленитесь и не используйте стандартные программы-ститчеры (склейщики панорам) в реальном времени для мобильных устройств. Соберите материал "в поле", придите домой, обработайте. Результат будет в разы лучше, потому что вы сможете его предварительно настраивать, править, доводить до состояния, когда он начнёт нравиться. Запомните одну важную истину: "У сшитой панорамы уже при всём желании никакой "Photoshop" быстро и просто не позволит, например, выправить горизонт". То есть если сразу "в поле" собираете панораму приложением на смартфоне - права на ошибку просто нет. Косячить нельзя. Если же вы "в поле" только собираете материал, то косячить с горизонтом, вообще говоря, можно в рамках довольно широкой полосы допуска. Главное не косячить с перекрытием соседних кадров. Не жалейте кадры. Не надо фотографировать стык в стык - это ошибка. Не бойтесь наложения кадров - эта избыточность и есть информация, которая нужно программе-сборщику. Так вот, если, всё же, ошиблись немного с горизонтом - не беда, всё можно будет вертикалями выправить на компьютере. Это должно привести к пониманию, что съёмка материала с рук возможна - совсем, совсем не обязательно таскать с собой штатив. Да, если ошиблись с горизонтом - это займёт некоторое дополнительное время на правку, но это не какие-то титанические усилия и манипуляции, а лишь немного терпения.

В общем, успехов всем в сборке. Жду вопросов в комментариях. Присылайте первые попытки ваших работ. Постараюсь объективно оценить и что-то посоветовать. Не бойтесь пробовать. Свой первый планетоид я отснял во дворе дома на детской площадке ранним утром, пока никого там не было. Кстати не на зеркальный фотоаппарат. Как и просто в фотографии - важно пробовать, тренироваться, иначе, вообще говоря, никогда и ничего не получится. Только ошибаясь можно двигаться дальше.

Рисунок 1 - Исходное представление планетоида в "Adobe Photoshop" с подсветкой инструмента "Волшебная палочка"
"ДАЛЕЕ ОСТАЛЬНЫЕ ИЛЛЮСТРАЦИИ"

Серия сообщений "Autopano Giga":
Часть 1 - AUTOPANO GIGA 2. ИНСТРУМЕНТ ДЛЯ СОЗДАНИЯ ПАНОРАМ. НАЧИНАЕМ ОБЗОР. ЧАСТЬ 1
Часть 2 - AUTOPANO GIGA 2. ИНСТРУМЕНТ ДЛЯ СОЗДАНИЯ ПАНОРАМ. НАЧИНАЕМ ОБЗОР. ЧАСТЬ 2
...
Часть 5 - РУКОВОДСТВО -НА ПАЛЬЦАХ- ПО СБОРКЕ ПЛАНЕТОИДОВ. ЧАСТЬ 2
Часть 6 - РУКОВОДСТВО -НА ПАЛЬЦАХ- ПО СБОРКЕ ПЛАНЕТОИДОВ. ЧАСТЬ 3
Часть 7 - РУКОВОДСТВО -НА ПАЛЬЦАХ- ПО СБОРКЕ ПЛАНЕТОИДОВ. ЧАСТЬ 4