useless: почему-то гит видит тут изменения

CONTRIBUTING.md

@@ -24,7 +24,7 @@ tags:
 
 ### Служебные теги
 
-Все служебные заметки начинаются со специальной комбинации `#служебные/`
+Все служебные заметки начинаются со специальной комбинации `#служебное/`
 
 - #служебное/доработать - заметка в целом закончена, но нужно внести некоторые доработки
 - #служебное/в_процессе - заметка по каким-то причинам отложена и не закончена

Билеты/02 - Алгоритмы сжатия. Без потерь, JPEG, MPEG.md

@@ -0,0 +1,81 @@
+---
+tags:
+  - служебное/в_процессе
+pun: Дай человеку рыбу и он будет сыт один день. Назови человека Сыт и он будет Сыт всегда
+---
+*Подробно про все алгоритмы сжатия написано у меня в [[Глава 2. Виды данных, их кодирование, команды#Всякие там алгоритмы сжатия|конспекте]], здесь же я просто пробегусь по методичке*
+
+## Сжатие без потерь
+
+**Типы алгоритмов сжатия без потерь:**
+
+1. Поточные и словарные алгоритмы - сжатие на основе ранее встречавшихся последовательностей
+2. Алгоритмы статистического (энтропийного сжатия) - используется информация о "частоте встречания" каких-то символов и использование наиболее коротких кодов для символов, которые встречаются чаще всего
+
+### RLE
+
+Групповое кодированиеRLE - *(run-length encoding)* - Серия повторяющихся величин заменяется двумя: значением и количеством. Цепочка из n одинаковых байтов (при байт/пиксел) будет заменена двумя байтами
+
+###  Кодирование по Хаффману
+
+Все прям по задачке из ЕГЭ - вот последовательность символов - закодируйте ее неравномерным кодом так, чтобы длина была минимальной и все можно было однозначно раскодировать
+
+*Препод пишет следующее*
+
+> Используются коды переменной длины, причем более короткие комбинации для более часто встречающихся величин. Для эффективного кодирования надо иметь статистику: как часто встречаются разные значения - поэтому кодирование "в два прохода". Степень сжатия также зависит от типа изображения - плохо работает для файлов, содержащих длинные последовательности одинаковых пикселов. Процессы кодирования и декодирования - сравнительно медленные процессы. Алгоритм очень чувствителен к "потере" битов в закодированных данных.
+
+### LZW (Lempel-Ziv-Welch)
+
+Это целое семейство алгоритмов, основой которых является идея о том, кодировать данные частями этих самых данных. 
+
+В процессе сжатия данных мы читаем файл и попутно собираем словарь, к которому обращаемся, когда находим совпадения
+
+*Препод пишет:*
+
+> Используется в архиваторах. Подобно алгоритму Хаффмана заменяет длинные последовательности более короткими, но не требует предварительно собирать статистику, он формирует все более эффективную 80 таблицу кодирования по мере продвижения по шифруемому массиву. Более "шумные" изображения кодируются хуже. Поэтому иногда рекомендуется подавить низкочастотной фильтрацией высокие пространственные частоты на изображении Типичные коэффициенты сжатия между 1:1 и 1:3, хотя иногда м.б. и 1:10. Этот алгоритм используется в графических форматах GIF и TIFF
+
+## Сжатие с потерями
+
+### JPEG
+
+*Те еще танцы с бубном и самое длинное описание алгоритма в конспекте. Здесь я подробно приводить не буду и ограничусь методичкой*
+
+Идейно базируется на биологии человеческого глаза - в нашем глазу в десятки раз больше рецепторов, отвечающих за восприятие яркости и зрение в темноте, чем рецепторов отвечающих за зветное зрение. Поэтому логично как будто бы кодировать в основном информацию о яркости, а информацию о цвете частично выкидывать и при этом наш глаз не заметит большой разницы
+
+Вторая идея - на художественном изображении или фотографии 2 рядом стоящих пикселя как правило близки по цвету
+
+Этапы следующие:
+
+- Конвертнуть изображение из RGB в YCbCr, для того, чтобы компонента яркости $Y$ стала явной
+- Сразу же избавиться от части информации о цвете (глаз все равно не заметит. а уже на этом этапе изображение уменьшается в 2 раза)
+- Разбить изображение на блоки 8х8. Для каждого канала (Y, Cb, Cr) это делается отдельно. Для я яркости используется разбиение по 16x16 дискретные косинусные преобразования[^1]
+- Значения, получившиеся после преобразования делят на опытным путем найденные числа[^2]. и округляют результат деления до целого. В матрице при этом возникает много нулей - что нам и нужно
+- Получившиеся блоки с кучей нулей сжимают алгоритмом сжатия без потерь (отлично подходит RLE). При этом коэффициенты для деления в предыдущем шаге специально подобраны так, чтобы чем ближе к нижнему правому концу матрицы, тем больше нулей, поэтому кодируем под RLE мы не при помощи записи матрицы по строкам, а как бы зигзагом. В конце ставится специальный байт, означающий конец этого блока
+- Чтобы еще сильнее сжать информацию, ее переводят в битное представление, после чего применяют алгоритм Хаффмана, чтобы оно занимало как можно меньше места в битах. При этом все таблицы для алгоритма Хаффмана составлены заранее, чтобы не тратить на них место
+- Итоговый результат записывается в файл в виде блока. Потом процесс повторяется отдельно для каждого канала (Y, Cb, Cr) отдельно и выходные данные пишутся в файл вместе с другой служебной информацией, которая нужна будет для расшифровки данных
+
+Это тут я еще упростил, но Препод написал и то меньше, так что этого должно хватить на приличный ответ.
+
+[^1]: Дело в том, что было доказано, что все значения в таких матрицах представимы в виде комбинации заранее определенных 64 узоров с разными коэффициентами. Мы делаем это страшное преобразование для того, чтобы эти коэффициенты найти. Подробнее об этом написано в конспекте
+[^2]: Каждой ячейке соответствует свое число. Их можно записать в виде матрицы, где каждой ячейке получившейся в результате дискретных косинусных преобразований матрицы, будет соответствовать (находящаяся на той же строке и в том же столбце) ячейка другой матрицы. Вторая матрица называется матрицей квантования
+### MPEG
+
+Фактически базируется на JPEG и разделяет с ним идеи. Помимо них добавляется еще одна:
+
+- Между двумя отдельными кадрами видео изменения как правило малы
+
+Краеугольным камнем всего формата являются кадры двух типов: I -  кадры, сжатые полноценно и независимо, и P - кадры, которые построены с ссылкой на предыдущий (при этом учитывается как изменение пикселей, так и смещение отдельных блоков пикселей в пространстве)
+
+Для еще большего сжатия появляются B-кадры, которые вообще говоря генерируются, а не строятся на основе исходного видеоряда. Получаются они некоторым подобием среднего арифметического двух соседних кадров категорий I и P
+
+![[Глава 2. Виды данных, их кодирование, команды#^9aa8aa]]
+
+Степень сжатия можно повысить следующими способами (не очень точный пересказ методички):
+
+![[Глава 2. Виды данных, их кодирование, команды#Основные пути повышения степени сжатия]]
+
+### Motion-JPEG
+
+Видео представляет собой последовательность из изображений - кадров. Если закодируете каждый из этих кадров алгоритмом JPEG независимо, то получите Motion-JPEG (M-JPEG). Он применяется при монтаже видео и позволяет реализовывать прикольную прокруту по кадрам, так как обеспечивает одну из самых больших скоростей доступа к произвольному кадру
+
+Работает он быстро так как в наше время во многих процессорах есть аппаратное ускорение различных операций над JPEG

Дополнительно/Глава 2. Виды данных, их кодирование, команды.md

@@ -14,6 +14,7 @@ source:
 ### Форматы для хранения графических данных
 ### Краткая характеристика наиболее распространенных растровых форматов
 
+## Всякие там алгоритмы сжатия
 ### Алгоритмы сжатия без потерь
 
 Неплохое видео: https://www.youtube.com/watch?v=CJFUN6BrkGE
@@ -148,4 +149,44 @@ JPEG - формат хранения изображения с потерями.
 
 В целом этот алгоритм позволяет сжимать изображения в десятки раз. (вплоть до 50-кратного уменьшения размера)
 
+Повторим еще раз идейно наши шаги:
 
+```mermaid
+graph TD;
+	convert(Перекодировать цвета, чтобы появился явный параметр яркости)-->resize(Выкинуть часть информации о цвете, которую глаз не заметит);
+	resize-->split(разбить изображения по каналам, а содержимое каналов поделить на группы по 8х8 для цветов и по 16х16 для яркости);
+	split-->DCT(Выявить какие узоры из числа заранее известных 64-х в каких пропорциях присутствуют в группах);
+	DCT-->clean(выкинуть все несущественные узоры);
+	clean-->compress(Оставшиеся коэффициенты матрицы компактно упаковать);
+	compress-->Готово!;
+```
+
+### MPEG
+
+*Сжимаем видео*
+
+Фактически базируется на JPEG и разделяет с ним идеи. Помимо них добавляется еще одна: ^fe65ee
+
+- Между двумя отдельными кадрами видео изменения как правило малы
+
+Краеугольным камнем всего формата являются кадры двух типов: I -  кадры, сжатые полноценно и независимо, и P - кадры, которые построены с ссылкой на предыдущий)
+
+В целом уже довольно сильное сжатие можно было бы достичь и этим, но мы пошли чуть дальше и ввели категорию B - кадры, которые ссылаются на следующий и предыдущий кадры. В реализациях классического MPEG алгоритма они вообще просто генерируются на основании двух ближайших кадров категорий I и P. Обычно являются неким "средним арифметическим" между этими двумя кадрами. на эту категорию ничего не ссылается
+
+Примерное кодирование выглядит так: нeзависимо кодируется кадр видео целиком. Обычно кодируются каждый пол секунды видео. Затем если мы говорим про частоту кадров в 24 кадра/секунду, то на равных промежутках вставляется еще 3 кадра категории P. Они кодируются, как и было сказано, со ссылкой на предыдущий кадр. А дальше добивается это дело B-кадрами. Судя по описанию методички их по факту даже нет в исходном видеоряде. Они просто строятся на основе двух соседних кадров^[Чем-то напоминает dlss если вы понимаете о чем я]. Обычно кодирование ведется группами по N кадров. Такие группы могут декодироваться независимо от других групп. Обычно размеры группы естественным образом определяются расстоянием между кадрами типа I. ^9aa8aa
+
+Говоря о самих изображениях, они состоят из макроблоков (размером 16х16 пикселей %%ничего не напоминает?)%%). Такие блоки имеют привычку смещаться и немного изменяться со временем. Вот их смещения обычно отслеживают и сжимают. Сжатие происходит очень сходно с JPEG
+
+#### Основные пути повышения степени сжатия
+
+- Улучшение сжатия I-кадров
+- Улучшение подбора векторов смещения блоков (исходно - среднеквадратичное смещение%%Я тоже не в курсе, что за смещения векоторов. Такое чувство, что Молодяков тут не объясняет а напоминает%%)
+- Если у вас еще остались тяжелые наркотики можете посравнивать коэффициентики в соседних блоках 8х8. Там адовы преобразования можно усреднить значения соседних блоков и добавить степени сжатия
+- Если сжать кадры слишком сильно, то будут видны края блоков, но в целом можно алгоритмами убирать их на пост обработке и продолжать увеличивать сжатие
+- Можно предварительно обработать видео, чтобы оно лучше подходило для сжатия (вырезать многие детали, которые все равно не заметны), вырезать разные шумы и "высокие частоты"^[Молодяков их так назвал. Что это в контексте изображения - ума не приложу]
+
+### Motion-JPEG
+
+Если видео короткое, или вам в целом все равно, что один видосик будет занимать у вас пол диска, то можно обойтись и Motion-JPEG (M-JPEG). Он заключается в основном в том, что все кадры будут независимо сжаты при помощи JPEG. 
+
+Это помогает при монтаже видео и в целом JPEG обладает аппаратным ускорением^[То есть в процессоры вмонтированы устройства подобные тем, что мы на схемаче собираем, которые гоняют только операции над JPEG и ничем другим не занимаются. За счет того, что такие сопроцессоры не программируются а один раз собраны, скорость обработки получается очень быстрой]