Ускорение JPEG-кодирования с использованием нескольких потоков

[BigDflz]

зачем постить об умирающем формате? на том же javascript в браузере можно достичь приличных результатом используя воркеры.
лучше написать о AVIF, как из jpeg сделать avif на java, js…

[mistergrim]

Я раньше умру, чем этот формат.

[middle]

«Он ещё спляшет на наших похоронах!» (с)

[bolk]

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

[denisshabr]

Не появится. Я тоже ждал, но не будет, это принципиальная позиция разработчиков браузера вот уже несколько лет. Скорее JPEG XL поддержут, в который можно без потерь lossless перекодировать существующие jpeg с -20% за счёт этого арифметического кодирования. Причём там и поддержка старых обычных Jpeg есть на уровне формата. И Google принимает участие в его создании. Вот кстати только 25 декабря 2020 битстрим формата утвердили и заморозили.

[VEG]

Google уже пилит поддержку JPEG XL в Chromium. В Mozilla пока ещё только обсуждают.

[bolk]

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

[VEG]

Я пытался продвинуть идею поддержки арифметического кодирования в Chromium. Для этого нужно было дорабатывать libjpeg-turbo: там была неполная поддержка JPEG с арифметическим кодированием (как раз в той части API что нужно браузерам), и отсутствовала оптимизация кода декодирования таких JPEG. Автор libjpeg-turbo сказал что на энтузиазме это делать не будет, спонсор не нашёлся, на этом всё и остановилось.

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

[denisshabr]

Вот по последнему абзацу хотелось бы подробней. За счёт чего возможно получить выигрыш при lossless пережатии? Я так думал только за счёт сжатия данных арифметическим кодированием, всё остальное вроде как не lossless. Ну по минимуму там ещё хидеры и exif пожать чем-нибудь, сейчас они несжаты в jpeg.

Процесс пережатия jpeg<>jpegxl уже сейчас можно попробовать через утилиту Brunsli (обещают 22%), в целом пока польза от этой утилиты такая же, что и от Packjpg, Dropbox Lepton,StuffIt, WinZip, и ImageMagic/arithmeticjpeg. Кстати, ежегодное сравнение подобных утилит здесь было www.squeezechart.com (но уже 2 года не обновляется).

[VEG]

Ну так же как и JPEG с арифметическим кодированием, Brunsli заменяет deflate на какой-то более современный алгоритм, а внутренние структуры остаются те же.

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

[DistortNeo]

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

Вот результаты этого испытания.

Неплохо бы ещё размер изображения указать. Если это 1200×500 (размер изображения статье), то скорость работы на порядок ниже, чем у остальных реализаций. Тот же libjpeg-turbo на более-менее современном процессоре выдаёт порядка 150-200 Мпикс/сек, у вас же получается только 10 МПикс/сек в 6-поточном режиме.

[foxin]

Поэтому проще использовать эффективный однопоточный декодировщик

проще — да, лучше — вряд ли. берем мобильные девайсы — чем больше ядер задействуем, тем энергоэффективнее решится задача. да, пользователю по барабану, будет ли картинка декодироваться 3мс или 30мс. но не по барабану, сколько у него останется батареи через 2 часа: 3% или 30%.

[DistortNeo]

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

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

[svr_91]

Странно, что кодирование изображения занимает больше времени, чем декодирование. (Я сам сталкивался с этим в свое время, когда писал свой алгоритм кодирования jpeg). Хотя вроде бы кодирование имеет больше «гибкости» в плане выбора удобных для себя параметров, чем декодирование

[CopterSpace]

На Raspberry PI 3 поток кадров с камеры 1280×960 25 FPS — не успевал сохраняться на флешку SD в реальном времени с помощью OpenCV VideoWriter, в MJPG.
Поэтому — да, вариантом решения было — читать кадры в память, и писать их параллельно 2-мя и более VideoWriter-ами.
Так что задача ускорения кодирования (с помощью распараллеливания) — актуальна. И распараллеливание с ускорением каждого кадра — имхо, лучше, чем потом синхронизировать несколько VideoWriter-ов между собой.

[foxin]

а вы учитывали, что данные на sd пишутся блоками по 16(?) МБ и оптимизировали размер чанка, отправляемого на запись?

[CopterSpace]

Нет, не учитывали. У VideoWriter таких и настроек — то нет, он кадры как-то последовательно пишет.
Зато у него есть, смотрю, cv.VIDEOWRITER_PROP_NSTRIPES — число параллельных потоков, при случае проверю, влияет ли на запись....

[AndreyDmitriev]

У меня была задачка про быстрое сжатие, правда не «классический» JPEG, a JPEG 2000. Некая железка отдавала шестнадцатибитные картинки 4048x4048 со скоростью 4 кадра в секунду. Ну то есть 120 мегабайт в секунду прилетало. Причём жать надо было хитро — была задана область, в которой сжатие должно было осуществляться без потерь (благо JPEG 2000 это позволяет). Я решил задачу простейшим способом, обрабатывая каждую картинку отдельным процессором, но мне было бы куда как удобнее, чтобы вместо «макро» параллелизма был «микро» параллелизм, поскольку серии картинок надо было в порядке поступления складывать в контейнер. Я полистал спецификацию формата и прикинул, что параллелить на этапе кодирования — работы слишком много.