[repstosw 18]

Сделал 4 ступени вейвлет-преобразований для изображения (по обеим осям).  В качестве вейвлета взял DB4 (устраняет постоянную составляющую и линейную зависимость цвета).

Размер кадра 160x240. Ступени: 80x120, 40x60, 20x30, 10x15

Получившиеся коэффициенты - меньше 0 и больше 255:

 

Вопрос - что с ними делать дальше?   Пока просто их проквантовал линейно от 0 до 255:

y[0..255]=f(x)=k*x+b

k=255/(max-min)

b=-k*min

Получилась вот такая визуализация разложения:

 

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

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

Ещё статьи умные почитал, советуют НЧ блок (в самом левом верхнем углу) - кодировать АДИКМ (а не Арифметическим кодером как в JPEG2000), чтобы искажения не сильно гробили картинку на выходе.

 

Собственно, вопросы:

1. Каким квантователем квантовать?  Пока выбран линейные квантователи - отдельно для каждого шага: [0..255]

2. Как упорядочивать данные , иначе - в какой последовательности передавать?

3. Весовые коэффициенты, какие взять?  На счёт НЧ - понятно, что это самое значимое, а для остальных сегментов?

4. Какой кодер брать - Хаффман , Арифметический, или?

 

 

Изменено 26 ноября, 2023 пользователем repstosw

[_pv 52]

0) уверены что (особенно на таких картинках) будет хоть какой-то заметный выигрыш по сравнению с обычным jpegом?

123) когда-то делал подглядывая сюда: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/12/msri_jpeg.pdf

4) арифметический лучше, особенно для сильных степеней сжатия (Хаффман меньше бита на символ не может сделать), но вычислений больше.

В процессе "облегчения" для упихивания в какой-то немощный МК оно вроде как-то работало даже с простой суммой/разностью в качестве НЧ/ВЧ фильтров, и "от балды" руками подобранными коэффициентами квантования целиком просто по степеням разложения.

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

Идея была тоже была по совсем уж узкому радиоканалу картинку, а то и видео получать (с трехмерным, ещё и по времени преобразованием, а не только 2D). но в конце концов победили мощные ГГц передатчики и аналоговое видео поверх :) и за прошедшие 15-20 лет что-то не особо сильно ситуация поменялась, заглянул на ютуб там куча совсем не старых роликов, где выясняют что же лучше аналоговое или цифровое видео для fpv.

А вот запихивать в кодек ещё и коррекцию ошибок имхо не самая замечательная идея, этим протокол передачи заниматься должен.

[blackfin 16]

On 11/26/2023 at 1:06 PM, repstosw said:

Собственно, вопросы:

1. JPEG 2000

2. JPEG XS

[repstosw 18]

25 minutes ago, _pv said:

А вот запихивать в кодек ещё и коррекцию ошибок имхо не самая замечательная идея, этим протокол передачи заниматься должен.

Сделал "длинный" кодек Рида-Соломона - на весь пакет, который со своей избыточностью 25% сможет исправить 12,5% ошибок или 25% стираний. Мне это показалось недостаточным, хотя умные статьи как раз говорят о том, что если в пакете свыше 25%  ошибок, то канал очень плохой и нужно искать либо другой канал, либо другие методы улучшения приёма.

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

Традиционный JPEG для этого ипользует сбросы квантователей и опорные маркеры, а JPEG2000 со своей JPWL не спасает на пакетных ошибках.  Поэтому приходится делать своё, так как всё что есть - просто не подходит для передачи по эфиру.  Любая порча бита (даже при BER 10^-6) приведёт к отказу декодирования.

Поэтому есть мысль сделать FEC на каждую ступень, и при невозможности её восстановления (более 12,5% битых данных) - просто "занулять" коэффициенты этой ступени или применять её "как есть".

Плюс есть ещё идея - ввести стирания в общий RS-код,  сейчас символ - 12 бит, сделать 11 бит данные и 1 бит - проверка чётности.   Если чётность символа не сходится - значит по-любому стирание, иначе неизвестно.  Что увеличит число исправлений в пределе до 25%

 

13 minutes ago, blackfin said:

1. JPEG 2000

2. JPEG XS

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

Изменено 26 ноября, 2023 пользователем repstosw

[blackfin 16]

On 11/26/2023 at 3:07 PM, repstosw said:

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

Стандартный подход для решения этой проблемы состоит в разбиении всего кадра на полосы высотой от ~16 до ~32 строк (slices) и кодировании каждой такой полосы независимо от остальных. При обнаружении ошибки в такой полосе, вся поврежденная полоса кадра заменяется на "копию" из предыдущего кадра.

[repstosw 18]

5 minutes ago, blackfin said:

Стандартный подход для решения этой проблемы состоит в разбиении всего кадра на полосы высотой от ~16 до ~32 строк (slices) и кодировании каждой такой полосы независимо от остальных. При обнаружении ошибки в такой полосе, вся поврежденная полоса кадра заменяется на "копию" из предыдущего кадра.

Насколько увеличится оверхед при "кусочном" кодировании и насколько хороша "сшиваемость" блоков - швы будут ?

[blackfin 16]

On 11/26/2023 at 3:24 PM, repstosw said:

Насколько увеличится оверхед при "кусочном" кодировании и насколько хороша "сшиваемость" блоков - швы будут ?

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

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

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

[repstosw 18]

Почему в JPEG2000 используются вейвлеты LeGall 5/3 и CDF 9/7 ?   Чем они хороши по сравнению с DB4 или тем более с DB6,8,... и т. п.

Понятно, что вейвлеты более высших порядков усложняют расчёт и нагружают процессор. Есть ли другие причины использовать именно  LG 5/3 и CDF 9/7 ?

Есть ли выигрыш в сжатии от использования вейвлетов более высших порядков?

Или преобразования Хаара (DB2) будет достаточно?

Насколько прямо зависит степень сжатия от числа ликвидирующих моментов(порядок вейвлета) ?

Есть соблазн использовать DB6, 8 для устранения квадратичного и кубического цветового и светового градиента  в изображении, но это реально даст выигрыш в сжатии или сократит число ступеней преобразований (при том же сжатии)?

Изменено 26 ноября, 2023 пользователем repstosw

[_pv 52]

Для этого надо построить графики ошибки сжатия от степени сжатия бит/пиксель для разных вэйвлетов и разных характерных картинок.

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

[_4afc_ 25]

On 11/26/2023 at 3:55 PM, repstosw said:

Насколько прямо зависит степень сжатия от числа ликвидирующих моментов(порядок вейвлета) ?

Для понимания этого строится график PSNR. Хотябы от Y.

Фактически зависит от размера кадра XY в точках и количества мелких деталей на нём которые надо сохранить.

Пока вашего  паренька  видно - теоретически можно делить ещё.

Проверяется на ваших типовых видео последовательностях.

 

On 11/26/2023 at 3:55 PM, repstosw said:

Почему в JPEG2000 используются вейвлеты LeGall 5/3 и CDF 9/7 ? 

У меня 5/3 был 8 бит, а 9/7 - 16, соответственно 16 битное представление давало меньший PSNR.

[dtmf73 2]

Добрый день.

Могу посоветовать посмотреть здесь:

http://www.compression.ru/

Изменено 29 ноября, 2023 пользователем dtmf73

[petrov 6]

_pv

А вот запихивать в кодек ещё и коррекцию ошибок имхо не самая замечательная идея, этим протокол передачи заниматься должен.

Это правильная идея, совместные модуляция, сжатие, кодирование, иначе ещё сто лет лучше аналога делать будем.

[thermit 1]

55 минут назад, petrov сказал:

_pv

А вот запихивать в кодек ещё и коррекцию ошибок имхо не самая замечательная идея, этим протокол передачи заниматься должен.

Это правильная идея, совместные модуляция, сжатие, кодирование, иначе ещё сто лет лучше аналога делать будем.

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

[_4afc_ 25]

11 minutes ago, thermit said:

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

Потому что пуле (ошибке) всё равно в кого попадать. Поэтому сначала надо бронировать пилота (синхронизацию, заголовки).

Потом системы жизне-обеспечения (коэффициенты сжатия и корр коды). Пассажиры (данные) - в последнюю очередь.

[thermit 1]

14 минут назад, _4afc_ сказал:

Потому что пуле (ошибке) всё равно в кого попадать. Поэтому сначала надо бронировать пилота (синхронизацию, заголовки).

Потом системы жизне-обеспечения (коэффициенты сжатия и корр коды). Пассажиры (данные) - в последнюю очередь.

Ничего не понятно, но интересно. Смотрим дальше (цэ).