Разработка программного модуля цветовой коррекции изображения с использованием средств OpenGL

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Содержание

Введение

1. Анализ исходных данных и разработка технического задания

1.1 Характеристика требований на разработку

1.2 Анализ подходов к разработке аналогичного программного обеспечения

1.3 Выбор технологии проектирования

1.4 Специальное и общесистемное программное обеспечение

1.5 Разработка технического задания

2. Проектирование программного модуля цветокоррекции

2.1 Цветовая коррекция изображения при помощи градиентной карты

2.2 Цветовая коррекция при помощи трехмерной структуры

2.3 Цветовая коррекция с использованием буфера глубины

2.4 Проектирование библиотеки цветокоррекции

2.4.1 Разработка архитектуры приложения

2.4.2 Разработка диаграммы вариантов использования

2.4.3 Разработка диаграммы классов

2.4.4 Разработка диаграммы развертывания

2.4.5 Разработка диаграммы последовательности

3. Разработка и тестирование программного модуля цветокоррекции

3.1 Реализация шейдеров цветовой коррекции

3.1.1 Реализация шейдера цветовой коррекции при помощи градиентной карты

3.1.2 Реализация шейдера цветовой коррекции с помощью трехмерной структуры

3.1.3 Реализация шейдера цветовой коррекции с использованием буфера глубины

3.2 Реализация модуля цветной коррекции изображения

3.3 Реализация демонстрационной программы

3.3.1 Реализация загрузки трехмерной модели в сцену

3.3.2 Реализация загрузки текстурных карт

3.4 Разработка программной и эксплуатационной документации для модуля цветовой коррекции изображения с использованием средств OpenGl

3.4.1 Разработка описания программы

3.4.2 Разработка программы и методики испытаний

3.4.3 Разработка руководства системного программиста

3.4.3 Разработка руководства оператора

4. Экономическая часть

4.1 Обоснование необходимости разработки программного обеспечения

4.2 Структура работ по созданию программного обеспечения

4.3 Составление сметы затрат на разработку программного обеспечения

4.4 Расчет отпускной цены программного обеспечения

4.5 Экономическая эффективность внедрения программного обеспечения

5. Охрана труда

5.1 Промышленная санитария и гигиена труда

5.2 Техническая безопасность

5.2.1 Правила установки ПЭВМ и РЭА

5.2.2 Требования к организации и оборудованию рабочих мест

5.2.3 Требования к безопасности перед началом работы

5.2.4 Требования к безопасности при выполнении работы

5.2.5 Требования к безопасности при окончании работы

5.3 Электробезопасность

Заключение

Список литературы

Приложение А (обязательное). Техническое задание

Приложение Б (обязательное). Диаграмма вариантов использования

Приложение В(обязательное).Диаграмма классов

Приложение Г (обязательное). Диаграмма компонентов

Приложение Д (обязательное). Диаграмма последовательности

Приложение Е (обязательное). Описание программы

Приложение Ж (обязательное). Программа и методика испытаний

Приложение И (обязательное). Руководство системного программиста

Приложение К (обязательное). Структура программы

Приложение Л (обязательное). Руководство оператора

Введение

Стандарт OpenGL (Open Graphics Library - открытая графическая библиотека) был разработан и утвержден в 1992 году ведущими фирмами в области разработки программного обеспечения как эффективный аппаратно-независимый интерфейс, пригодный для реализации на различных платформах.

OpenGL является одним из самых популярных прикладных программных интерфейсов (API - Application Programming Interface) для разработки приложений в области двумерной и трехмерной графики.

Характерными особенностями OpenGL, которые обеспечили распространение и развитие этого графического стандарта, являются:

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

? надежность и переносимость. Приложения, использующие OpenGL, гарантируют одинаковый визуальный результат вне зависимости от типа используемой операционной системы и организации отображения информации. Кроме того, эти приложения могут выполняться как на персональных компьютерах, так и на рабочих станциях и суперкомпьютерах;

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

? описать возможности OpenGL можно через функции его библиотеки. Все функции можно разделить на пять категорий:

? функции описания примитивов определяют объекты нижнего уровня иерархии (примитивы), которые способна отображать графическая подсистема. В OpenGL в качестве примитивов выступают точки, линии, многоугольники и т.д.;

? функции описания источников света служат для описания положения и параметров источников света, расположенных в трехмерной сцене;

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

? функции визуализации позволяет задать положение наблюдателя в виртуальном пространстве, параметры объектива камеры. Зная эти параметры, система сможет не только правильно построить изображение, но и отсечь объекты, оказавшиеся вне поля зрения;

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

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

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

Для достижения поставленной цели были сформулированы следующие задачи дипломного проектирования:

- провести анализ предметной области;

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

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

- произвести отладку и тестирование данного программного продукта;

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

1. Анализ исходных данных и разработка технического задания

1.1 Характеристика требований на разработку

Задачу разработки программного модуля цветовой коррекции изображения с использованием средств OpenGL можно разделить на две части: реализацию шейдеров на языке GLSL, которые осуществляют цветовую коррекцию входного изображения, а также создание программного модуля на языке C++ с использованием OpenGL. Также необходимо разработать программу, которая будет демонстрировать работу модуля.

Модуль должен обеспечивать следующие функции:

- производить цветовую коррекцию несколькими известными способами;

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

Демонстрационная программа должна выполнять следующие функции:

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

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

Также в рамках дипломного проектирования следует разработать руководство пользователя для разрабатываемого программного модуля.

1.2 Анализ подходов к разработке аналогичного программного обеспечения

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

Самой большой сферой, где используется цветовая коррекция изображения в трехмерном пространстве, является игровая индустрия, поэтому при анализе рассматриваются современные игровые движки - Unreal Engine, CryEngine, Unity. У всех рассматриваемых движков цветовая коррекция реализована по схожему принципу, и каждый из этих движков может использовать цветовую коррекцию с применением различных методов её достижения. Реализация шейдеров в разных движках представлена на разных языках (HLSL, ShaderLab), что обусловлено их внутренней архитектурой. Методы же используются схожие:

- цветовая коррекция при помощи градиентной карты;

- цветовая коррекция при помощи трехмерной текстуры.

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

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

1.3 Выбор технологии проектирования

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

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

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

- CA ERwin Process Modeler (ранее: BPwin);

- CA ERwin Data Modeler (ранее: ERwin);

- Vantage Team Builder;

- Oracle Designer.

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

- IBM Rational Rose;

- Sybase PowerDesigner;

- Enterprise Architect.

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

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

Сравнение рассмотренных подходов в соответствии с выделенными критериями представлено в таблице 1.1.

Таблица 1.1 - Выбор Case-средств на основании сравнения разных подходов по проектированию программного обеспечения

Подходы	Структурный / Функциональный	Объектно-ориентированный	ARIS
Критерии средств	ERwin, Bpwin, Vantage Team, Builder, Oracle, Designer	Rational Rose, Power Designer, Enterprise, Architect	Aris Toolset
Глубина и комплексность анализа бизнес-процессов	+	-	+
Полнота описания и логическая целостность	+	-	+ / -
Наглядность	-	+	-
Структурность	+	-	+ / -
Гибкость и адаптируемость	+ / -	+	+ / -
Возможность генерации кода	+ / -	+	-
Распространенность	+	+ / -	-

В результате сравнения продуктов, можно сделать вывод о том, что средства, отвечающие структурному подходу (ERwin, BPwin), в основном находят свое применение на этапах определения требований к программному обеспечению. Такие средства подходят для осуществления глубокого анализа рассматриваемых процессов (Vantage Team Builder), позволяют максимально рационально расходовать ресурсы, вследствие независимости отельных компонент программного обеспечения (ПО). Что касается объектно-ориентированных средств, стоит отметить, что методика их применения позволяет осуществлять проектирование любого типа, по средству универсальности и наглядности языка UML, который используется в рамках Enterprise Architect, Rational Rose и Power Designer и является достаточно удобным инструментом для оперирования специалистами любого уровня подготовки [19].

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

1.4 Специальное и общесистемное программное обеспечение

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

Таблица 1.2 - Общесистемное и специальное программное обеспечение

Программное обеспечение	Назначение
Microsoft Word 2010	Программное обеспечение для работы с электронными документами
GLEW	Кроссплатформенная библиотека на C/C++, которая упрощает запрос и загрузку расширений OpenGL
GLFW	Кроссплатформенная библиотека для создания и открытия окон, создания OpenGL контекста и управления вводом

1.5 Разработка технического задания

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

Техническое задание оформляется в соответствии с ГОСТом 19.201-78 [10] и содержит следующие пункты:

а) основания для разработки;

б) назначение разработки;

в) требования к программе или программному изделию;

г) требования к программной документации;

д) стадии и этапы разработки;

е) порядок контроля и приемки.

Расширенное техническое задание приведено в приложении А.

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

а) реализация трех различных методов цветовой коррекции изображения;

б) среда Enterprise Architect для проектирования приложения;

в) библиотеки GLEW и GLFW для работы с OpenGL и реализации демонстрационной программы.

2. Проектирование программного модуля цветокоррекции

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

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

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

- проектирование демонстрационного приложения.

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

2.1 Шейдерные программы

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

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

В настоящее время шейдеры делятся на три типа: вершинные, геометрические и фрагментные (пиксельные).

2.1.1 Вершинные шейдеры

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

2.1.2 Геометрические шейдеры

Геометрический шейдер, в отличие от вершинного, способен обработать не только одну вершину, но и целый примитив. Это может быть отрезок (две вершины) и треугольник (три вершины), а при наличии информации о смежных вершинах (adjacency) может быть обработано до шести вершин для треугольного примитива. Кроме того, геометрический шейдер способен генерировать примитивы «на лету», не задействуя при этом центральный процессор. Впервые начал использоваться на видеокартах Nvidia серии 8.

2.1.3 Фрагментные шейдеры

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

2.1.4 Шейдерные языки

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

Шейдерные языки обычно содержат специальные типы данных, такие как матрицы, семплеры, векторы, а также набор встроенных переменных и констант для удобной интеграции со стандартной функциональностью 3D API. Поскольку компьютерная графика имеет множество сфер приложения, для удовлетворения различных потребностей рынка было создано большое количество шейдерных языков.

GLSL (OpenGL Shading Language) -- язык высокого уровня для программирования шейдеров. Синтаксис языка базируется на языке программирования ANSI C, однако, из-за его специфической направленности, из него были исключены многие возможности, для упрощения языка и повышения производительности. В язык включены дополнительные функции и типы данных, например для работы с векторами и матрицами.

Основным преимуществом GLSL перед другими шейдерными языкми реального времени является кроссплатформенность.

2.2 Цветовая коррекция изображения при помощи градиентной карты

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

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

Рисунок 2.1 - Пример работы кривых

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

Для лучшего результата, мы будем использовать текстуру размером 1x256, так как текстуру меньшего размера не дадут достаточного качества. Прежде чем создать карту, пользователь должен произвести все цветовые преобразования, при этом он не должен ограничиваться только инструментом кривых. Большинство графических редакторов позволяют сохранить преобразования в отдельном файле настроек (к примеру «.acv» файлы для Adobe Photoshop).

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

Рисунок 2.2 - Пример исходной и полученной карты преобразования

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

Схема работы шейдера цветовой коррекции с помощью градиентной текстуры представлена на рисунке 2.2:



Рисунок 2.2 - Схема работы шейдера цветовой коррекции изображения с помощью градиентной текстуры

2.3 Цветовая коррекция при помощи трехмерной текстуры

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

Трехмерная текстура преобразования цвета позволяет исключить все недостатки цветовой коррекции при помощи одномерной текстуры.

На рисунке 2.3 показано, как представлена трехмерная текстура для цветовой коррекции.



Рисунок 2.3 - Пример трехмерной текстуры

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

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

Однако следует отметить, что данный метод цветовой коррекции изображения имеет некоторые недостатки:

- не решает проблему учета положения объектов в пространстве. Данный вид цветовой коррекции может обрабатывать изображение только попиксельно;

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

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

Схема работы шейдера цветовой коррекции с помощью трехмерной текстуры показана на рисунке 2.4:



Рисунок 2.4 - Схема работы шейдера цветовой коррекции изображения с помощью трехмерной текстуры

2.4 Цветовая коррекция с использованием буфера глубины

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

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

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

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

Схема работы цветовой коррекции изображения с использованием буфера глубины показана на рисунке 2.5

2.5 Проектирование библиотеки цветокоррекции

2.5.1 Разработка архитектуры приложения

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

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

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

2.5.2 Разработка диаграммы вариантов использования

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой при помощи так называемых вариантов использования. При этом актером называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой[3]. На основании выше сказанного была построена UML-диаграмма вариантов использования, представленная в приложении Б.

Более подробно описание вариантов использования представлено в таблице 2.1. Таблица содержит описания общих вариантов использования, не включая расширения и включения.

Таблица 2.1 - Варианты использования

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

2.5.3 Разработка диаграммы вариантов использования

Диаграмма классов по праву занимает центральное место в объектно-ориентированном подходе. Фактически любая методология включает в себя некоторую разновидность диаграмм классов.

На основании диаграммы вариантов использования (см. приложение Б) была разработана диаграмма классов, описание которой приведено в таблице 2.2, представленная в приложении В.

Таблица 2.2 - Описание классов

Название варианта использования	Описание
Controls	Класс, обеспечивающий обзор сцены при помощи мыши
ModelLoader	Класс, обеспечивающий загрузку трехмерной модели в формате Wavefront OBJ
ShaderLoader	Класс, обеспечивающий загрузку шейдерных программ
FontManager	Класс, обеспечивающий загрузку шрифтов из текстуры и вывод текста на экран
TextureLoader	Класс, обеспечивающий загрузку двухмерных и трехмерных текстур в форматах DDS и BMP
IndexerVBO	Класс, обеспечивающий индексацию буфера вершин
ColorCorrection	Класс, обеспечивающий цветовую коррекцию изображения
RenderToTexture	Класс, обеспечивающий отрисовку изображения и буфера глубины в текстуру

2.5.4 Разработка диаграммы компонентов

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

2.5.5 Разработка диаграммы последовательности

Диаграмма последовательности - диаграмма, на которой показано взаимодействие объектов (обмен между ними сигналами и сообщениями), упорядоченное по времени, с отражением продолжительности обработки и последовательности их проявления. Используется в языке UML. Приложение Д.

3. Разработка и тестирование программного модуля цветокоррекции

Разработка программного продукта состоит из модуля цветовой коррекции изображения и демонстрационной программы.

Модуль цветовой коррекции изображения включает в себя:

- три фрагментных и один вершинный шейдер цветовой коррекции;

- классы TextureLoader, ShaderLoader и ColorCorrection.

Демонстрационная программа включает в себя:

- шейдер поверхности (поддержка диффузной карты, карты нормалей и карты отражений);

- шейдер для отображения текста;

- классы Controls, ModelLoader, FontManager, IndexerVBO и RenderToTexture.

3.1 Реализация шейдеров цветовой коррекции

Шейдеры цветовой коррекции реализовывались на шейдерном языке GLSL (при разработке использовалась шейдерная модель 3.3). Для цветовой коррекции разработано два вида шейдеров - вершинный шейдер, который является общим, и три фрагментных шейдера, для каждого типа цветовой коррекции.

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

3.1.1 Реализация шейдера цветовой коррекции при помощи градиентной карты

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

Шейдер цветовой коррекции изображения с помощью градиентной карты включает в себя следующую последовательность действий:

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

б) покомпонентная цветовая коррекция каждого цвета исходного значения и сборка всех цветовых компонент в один вектор цвета (выходное значение.

Реализация шейдера цветовой коррекции с помощью градиентной карты выглядит следующим образом:

#version 330 core

in vec2 UV;

out vec3 color;

uniform sampler2D _MainTex;

uniform sampler2D _RampTex;

uniform float time;

void main()

{

vec4 inColor = texture(_MainTex, UV);

color = vec3(texture(_RampTex, vec2(inColor.r,0)).r,

texture(_RampTex, vec2(inColor.g,0)).g,

texture(_RampTex, vec2(inColor.b,0)).b);

}

3.1.2 Реализация шейдера цветовой коррекции с помощью трехмерной текстуры

Разработанный шейдер также является фрагментным, и работает по следующему алгоритму:

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

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

Реализация шейдера цветовой коррекции с помощью трехмерной текстуры:

#version 330 core

in vec2 UV;

out vec3 color;

uniform sampler2D _MainTex;

uniform sampler3D _LookupTex;

uniform float time;

void main()

{

vec3 inColor = texture(_MainTex, UV).xyz;

color = texture(_LookupTex,vec3(inColor.r,inColor.g,inColor.b)).xyz;

}

3.1.3 Реализация шейдера цветовой коррекции с использованием буфера глубины

Алгоритм работы данного шейдера является самым сложным и комплексным из всех, разработанных в рамках дипломного проекта:

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

б) получение значения буфера глубины необходимого фрагмента из текстуры буфера глубины (по UV-координатам);

в) линеаризация буфера глубины;

г) получение значения цветовой коррекции на близком расстоянии;

д) получение значения цветовой коррекции на дальнем расстоянии;

е) смешивание значений цветовой коррекции в нужном отношении (на основании значения буфера глубины).

Реализация шейдера цветовой коррекции с использованием буфера глубины выглядит следующим образом:

#version 330 core

in vec2 UV;

out vec3 color;

uniform sampler2D _MainTex;

uniform sampler2D _RampTex;

uniform sampler2D _DepthBuffer;

uniform sampler2D _DepthRampTex;

uniform float time;

void main()

{

vec4 inColor = texture(_MainTex, UV);

float zValue = texture(_DepthBuffer,UV).r;

float linearZ = (2.0 / (500 + 0.5 - zValue* (500 - 0.5)));

vec3 nearColor = vec3 (texture(_RampTex,vec2(inColor.r,0)).r,

texture(_RampTex,vec2(inColor.g,0)).g,

texture(_RampTex,vec2(inColor.b,0)).b);

vec3 farColor = vec3(texture(_DepthRampTex,vec2(inColor.r,0)).r,

texture(_DepthRampTex,vec2(inColor.g,0)).g,

texture(_DepthRampTex,vec2(inColor.b,0)).b);

color = vec3( mix(nearColor, farColor, linearZ));

}

3.2 Реализация модуля цветовой коррекции изображения

Разработанный модуль цветовой коррекции состоит из следующих классов:

- TextureLoader - класс загружающий двухмерные текстуры из файлов в форматах DDS и BMP, а также загружающий трехмерные текстуры из файла в формате BMP;

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

- ColorCorrection - класс, который предоставляет методы для применения цветовой коррекции к изображению.

3.3 Реализация демонстрационной программы

Демонстрационная программа должна демонстрировать работы модуля цветовой коррекции, поэтому при разработке были реализованы следующие функции:

- создание окна OpenGL;

- загрузка трехмерной модели в сцену;

- наложение на трехмерные модели текстурных карт и отрисовка трехмерной сцены в текстуру;

- отрисовка справки;

- отрисовка буфера глубины в текстуру;

- применение к полученным текстурам цветовой коррекции.

Внешний вид демонстрационной программы показан на рисунке 3.1.

Рисунок 3.1 - Внешний вид программы

3.3.1 Реализация загрузки трехмерной модели в сцену

В качестве формата для хранения трехмерной модели был выбран Wavefront OBJ. Это формат файлов описания геометрии, разработанный в Wavefornt Technologies для их анимационного пакета Advanced Visualizer. Формат файла является открытым и был принят другими разработчиками приложения трехмерной графики и может быть импортирован и экспортирован в множество различных программ.

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

OBJ является одним из самых популярных форматов передачи трехмерной компьютерной геометрии. Информация о внешнем виде объектов (материалы) передается в файлах-спутниках в формате MTL (Material Library).

OBJ файл содержит несколько типов определения:

«v 0.123 0.234 0.345 1.0» - вершина с координатами (x,y,z[,w]).

«vt 0.123 0.234 1.0» - текстурные координаты (u,v[,w]).

«vn 0.707 0.000 0.707» - нормали.

«f 1 2 3» - определение поверхности (сторон).

3.3.2 Реализация загрузки текстурных карт

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

Загрузка BMP файлов является тривиальной задачей, т.к. используются файлы без сжатия, которые представляют из себя последовательное описание цветов пикселей.

DDS (Direct Draw Surface) - формат хранения данных, разработанный корпорацией Microsoft для использования в DirectX SDK.

DDS чаще всего используется для хранения текстур и применяется во множестве 3d приложений, а также в современных 3d играх. Позволяет хранить текстуры как в сжатом, так и не в сжатом виде.

Эта особенность позволяет использовать DDS в консолях нового поколения, таких как Xbox360 и Play Station 3. DDS позволяет хранить текстурные массивы. Преимущество формата dds заключается в том, что благодаря поддержке видеокартами DXTn их драйвера могут выполнять сжатие текстур «на лету» (в OpenGL для этого используется инструкция GL_ARB_texture_compression), что экономит время, необходимое на декомпрессию сжатых текстур в таких форматах как Jpeg. Всё вышесказанное повышает быстродействие.

Использование формата DDS позволяет ещё и избежать появления «артефактов», которые возникают при сжатии, что сохраняет качество текстур.

3.3.3 Реализация шейдеров поверхности

Разработанный шейдер поверхности включает в себя обработку трех текстурных карт:

- Диффузная карта;

- Карта нормалей;

- Карта отражений.

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

Реализация шейдера поверхности выглядит следующим образом:

#version 330 core

layout(location = 0) in vec3 vertexPosition_modelspace;

layout(location = 1) in vec2 vertexUV;

layout(location = 2) in vec3 vertexNormal_modelspace;

out vec2 UV;

out vec3 Position_worldspace;

out vec3 Normal_cameraspace;

out vec3 EyeDirection_cameraspace;

out vec3 LightDirection_cameraspace;

uniform mat4 MVP;

uniform mat4 V;

uniform mat4 M;

uniform vec3 LightPosition_worldspace;

void main(){

gl_Position = MVP * vec4(vertexPosition_modelspace,1);

Position_worldspace = (M * vec4(vertexPosition_modelspace,1)).xyz;

EyeDirection_cameraspace = vec3(0,0,0) - (V*M* vec4(vertexPosition_modelspace,1)).xyz;

vec3 LightPosition_cameraspace = ( V * vec4(LightPosition_worldspace,1)).xyz;

LightDirection_cameraspace = LightPosition_cameraspace + EyeDirection_cameraspace;

Normal_cameraspace = ( V * M * vec4(vertexNormal_modelspace,0)).xyz;

UV = vertexUV;

}

3.4 Разработка программной и эксплуатационной документации для модуля цветовой коррекции изображения с использованием библиотеки OpenGL

Результатом разработки программной и эксплуатационной документации являются следующие документы:

- описание программы;

- программа и методика испытаний;

- руководство системного программиста;

- руководство оператора.

3.4.1 Разработка описания программы

Описание программы представляет собой документ, предназначенный для указания области применения программы, функционального состава, круга решаемых задач и технических и программных средств, необходимых для нормального функционирования. Также должна быть приведена логическая структура, описан способ начала работы. Описание программы составляется в соответствии с ГОСТ 19.402-2000 [11].

Описание программы приведено в приложении Е.

3.4.2 Разработка программы и методики испытаний

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

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

а) наиболее быстрым и оптимальным по использованию памяти является метод, использующий для цветовой коррекции градиентную карту;

б) наиболее продвинутым, но самым медленным (хотя и не на много) является метод, использующий буфер глубины;

в) методом, который дает наиболее тонкие возможности по цветовой коррекции (хотя и не применяющий её в зависимости от глубины), является метод, использующий трехмерную текстурную карту.

Список функций и описание результатов их тестирования описаны в таблице 3.1.

Таблица 3.1 - Результаты тестирования функций

Имя функции	Описание	Результаты тестирования
getViewMatrix()	Возвращает матрицу вида для организации вида камеры	Функция работает корректно
indexVBO()	Индексирует вершины модели	Функция работает корректно
loadOBJ()	Загружает трехмерную модель в формате Wavefront OBJ	Загрузка модели производится корректно
LoadShaders()	Загружает вершинную и фрагментную шейдерную программу	Функция работает корректно
loadBMP_custom()	Загружает текстуру в формате BMP без сжатия	Загружаемая текстура корректна
loadBMP_lookup()	Загружает трехмерную текстуру в формате BMP без сжатия	Загружаемая текстура корректна
loadDDS()	Загружает текстуру в формате DDS	Загружаемая текстура корректна
RenderImageToTexture()	Отрисовывает изображение в текстуру	Функция работает корректно
DepthBufferToTexture()	Отрисовывает буфер глубины в текстуру	Функция работает корректно
initText2D()	Загружает текстуру шрифтов	Функция работает корректно
printText2D()	Выводит текст на экран	Функция работает корректно
RampCorrection()	Производит цветовую коррекцию изображения с помощью градиентной текстуры	Функция работает корректно
3DLookupCorrection()	Производит цветовую коррекцию изображения с помощью трехмерной текстуры	Функция работает корректно
DepthCorrection()	Производит цветовую коррекцию изображения с помощью буфера глубины	Функция работает корректно

Программа и методика испытаний составляется и оформляется в соответствии ГОСТ 19.301-2000 [12].

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

3.4.3 Разработка руководства системного программиста

Руководство системного программиста оформляется в соответствии ГОСТ 19.503-79 [13].

Руководство системного программиста модуля цветовой коррекции изображения с использованием библиотеки OpenGL приведено в приложении З.

3.4.4 Разработка руководства оператора

Руководство оператора оформляется в соответствии ГОСТ 19.505-79 [14].

Руководство оператора модуля цветовой коррекции изображения с использованием библиотеки OpenGL приведено в приложении И.

4. Экономическая часть

4.1 Обоснование необходимости разработки программного обеспечения

Целью дипломного проектирования является повышение эффективности деятельности компании посредством разработки программного модуля цветокоррекции, позволяющего осуществлять продажу товаров и услуг в сети Интернет. Разработанный программный продукт будет использоваться на ЧУП Гейм-Мастер.

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

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

4.2 Структура работ по созданию программного обеспечения

Работа по созданию программного продукта делится на определенные этапы, которые в совокупности называются жизненным циклом программного обеспечения. Существует множество методик разбиения жизненного цикла программного продукта на этапы. Наиболее популярно следующее разложение жизненного цикла программного продукта, которое включает в себя следующие этапы:

а) проектирование общей системы;

б) реализация составных частей системы;

в) тестирование готового программного комплекса;

г) приём программного продукта заказчиком.

Суммарное время, отведённое графиком дипломного проектирования на разработку программного обеспечения, составляет 12 недель.

Этап “проектирование общей системы” является первым и наиболее важным в разработке программного продукта. Задача, поставленная на данном этапе перед разработчиком - определение общих требований к программному продукту. Кроме того, на этой фазе необходимо добиться в определенном смысле оптимального распределения функции системы, выбрать алгоритм и процедуры, а также обозначить системные компоненты и связь между ними. На данный этап отводиться 25% времени, то есть 3 недели.

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

Этап “тестирование” представляет собой совокупность тестов, которым подвергается после реализации готовый программный продукт. Все ошибки, которые будут выявлены на данном этапе, должны быть исправлены. На данный этап отводиться 12% времени, то есть 10 дней.

Этап “приём программного продукта заказчиком” представляет собой приемочные испытания. Целью данного этапа является испытание готовой системы заказчиком. По результатам данных испытаний программный продукт может быть отправлен на доработку в случае, если он не полностью удовлетворяет потребностям заказчика. На данный этап отводиться 13% времени, то есть 11 дней.

На рисунке 4.1 представлена диаграмма распределения времени по стадиям разработки.

Рисунок 4.1 - Диаграмма распределения времени по стадиям разработки

4.3 Составление сметы затрат на разработку программного обеспечения

Оценка стоимости программного обеспечения и определение экономического эффекта у разработчика предполагают составление сметы затрат, которая согласно Постановления Министерства экономики Республики Беларусь, Министерства финансов Республики Беларусь и Министерства труда и социальной защиты Республики Беларусь от 30.10.08 г. №210/161/151 «Об основных положениях по составу затрат, включаемых в себестоимость продукции (работ, услуг)», включает следующие статьи затрат:

1) материалы и комплектующие (используемые в процессе разработки и производства программного обеспечения) ();

2) электроэнергия ();

3) основная заработная плата разработчиков ();

4) дополнительная заработная плата разработчиков ();

5) отчисления в фонд социальной защиты населения и на обязательное страхование ();

6) амортизация оборудования и программного обеспечения ();

7) спецоборудование для научных (экспериментальных) работ ();

8) накладные расходы ();

9) прочие прямые расходы ().

1) По статье «Материалы» отражаются расходы на магнитные носители, бумагу, красящие ленты и другие материалы, необходимые для разработки ПО.

Результаты представлены в таблице 4.1.

Таблица 4.1 - Стоимость основных и вспомогательных материалов

Наименование	Цена, руб.	Количество	Общая сумма, руб.
Бумага А4(печать)	600	110	66 000
Бумага А1(печать)	10 000	6	60 000
Компакт диск DVD-RW	5 000	1	5 000
Всего	131 000

Общая стоимость материалов рублей.

2) Затраты на электроэнергию находятся исходя из продолжительности разработки программного обеспечения и тарифа за 1 кВт/ч. Разработка ПО длится 3 месяца, в месяце 21 рабочий день. Рабочий день составляет 8 часов. Мощность осветительных приборов равна 100 Вт, потребляемая мощность компьютера 100 Вт, т.е. суммарная потребляемая мощность 0,2 кВт. Тарифы на электроэнергию применяются согласно приложения к Декларации «Об уровне тарифов на электроэнергию, отпускаемую РУП Электроэнергетики ГПО «Белэнерго» для ЮЛ и ИП» на соответствующий период времени, когда разрабатывался программный продукт. Базовый тариф для юридических лиц с 01.03.2014 г. составляет 1390,5 руб. за 1 кВт/ч

Тогда затраты на электроэнергию рассчитываются по формуле:

 руб. (4.1)

3) Основной статьёй расходов на разработку программного обеспечения является заработная плата программиста. Оплата труда в Республике Беларусь осуществляется на основе Единой тарифной сетки (ETC), в которой представлены тарифные разряды и тарифные коэффициенты с учетом категории, должности, образования, сложности выполняемой работы.

Для расчета заработной платы правительственными органами устанавливается тарифная ставка 1-го разряда.

Основная заработная плата () является основной статьёй затрат при разработке программного обеспечения и рассчитывается по формуле [1, с.6]:

; (4.2)