LINUX.ORG.RU

Ищу консольные программы, которые умеют работать с jpeg (12 бит и/или арифметическое кодирование)

 


0

1

Собственно, сабж. Поддержка 12 бит не совсем официальна, но она есть в libjpeg. Поддержка африметического кодирования есть в GIMP. Вы можете проверить, поддерживается ли арифметическое кодирование в вашем браузере: https://files.catbox.moe/ilkxra.jpg - если видно радугу, значит поддерживается (картинка взята из статьи https://blog.benjojo.co.uk/post/not-all-jpegs-are-the-same)

Моя первая попытка, взять ImageMagick и задать ему разные опции -colorspace и -depth (опции кодирования я не нашел):

for dp in {8,12,16}; do for cs in `convert -list colorspace`; do convert test2.jpg -depth $dp -colorspace $cs -gravity center -auto-level -sharpen +2x3 -resize 256x256^ -crop 256x256+0+0 -auto-level -sharpen 1x0 jpeg-test-$cs-$dp.jpg;done;done

Как результат, 8 и 16-битные файлы идентичны до хешей, 12-битные отличаются, но identify все равно говорит, что оно 8-битное, видимо только пиксели немного иначе считались, а упаковалось оно в 8 бит. Из хорошего - удалось получить JPEG с CMYK внутри.

Вторая попытка была с ffmpeg:

for cc in `ffmpeg -pix_fmts 2>&1 | grep -E "^\S\S\S\S\S\s\S+\s+[0-9]+\s+[0-9]+" | cut -d" " -f2`; do ffmpeg -i test2.jpg -pix_fmt "$cc" -s 32x32 -y "ffmpeg-$cc.jpg";done

Сгенерилось очень много файлов вида:

ffmpeg-yuva420p.jpg
ffmpeg-gbrap16be.jpg
ffmpeg-bgr565be.jpg
ffmpeg-yuv444p.jpg
ffmpeg-pal8.jpg

По факту все они одинаковые, разница только в yuvj420p/yuvj422p/yuvj444p

Хочу много JPEG-файлов, очень разных и очень красивых. С арифметическим кодированием, с 12 битами, в CMYK, в каких-то RGBIQ (упоминается в стандарте, никогда такого не видел), и шобы фотошоп не надо было ставить и мышкой елозить.

Возможно треду место в Development, так как это нужно для тестирования моего собственного творчества (пишу редактор jpeg, обрастаю тестами)

Jpegtran точно умел арифметическое кодирование. Посмотри, в каком он пакете и от чего зависит. Раз libjpeg умеет, то посмотри его тесты и что в репозитории какого-нибудь Дебиана его использует. GraphicsMagick посмотри (не ImageMagick). Погугли гугловый jpg testing suite. Ну и в конце концов gimp можно скриптовать через gimp-foo или как-то так. Извини, что в общих словах: с телефона на ходу пишу.

d ★★★★
()

пишу редактор jpeg, обрастаю тестами

Проверка на некорректные входные данные будет? Я как-то делал программную обработку JPEG на основе jpege/jpegd (такой относительно известный миниатюрный кодер/декодер на плюсах), и оно мне начало валить программу. Оказалось, на входе был файл с битыми таблицами смещений, а jpegd их не границы не проверял и валился вместе с вызвавшей программой.

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от d

Jpegtran точно умел арифметическое кодирование. Посмотри, в каком он пакете и от чего зависит.

Это из пакета jpeg-tools, в который входит cjpeg, который умеет и в арифметическое кодирование и во много чего еще.

Раз libjpeg умеет, то посмотри его тесты и что в репозитории какого-нибудь Дебиана его использует.

https://github.com/libjpeg-turbo/libjpeg-turbo/raw/main/testimages/testorig12.jpg - единственная картинка, но мне этого более чем достаточно, спасибо за наводку.

Погугли гугловый jpg testing suite.

Есть такое https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/imagetestsuite/imagetestsuite-jpg-1.00.tar.gz - содержит много битых картинок (что хорошо), различные разрешения, но ни одной в 12 бит.


А вообще найти картинки в 12-битном jpeg оказалось непросто, и хотя все про него говорят, его «никто не видел». Наденные картинки никто не читает, за исключением ffmpeg и pvrg-jpeg. Первый считает, что пиксели упакованы в

mjpeg, yuv420p16le(12 bpc, pc, bt470bg/unknown/unknown)

Однако этот самый yuv420p16le упорно не желает кодировать обратно.

Пробовал различные заклинания с pvrg-jpeg, вроде такого:

pvrg-jpeg -iw 512 -ih 512 -JFIF -ql -a -p 12 -s test12.jpg -ci 1 -hf 4 -vf 4 xor -ci 2 -hf 4 -vf 4 xor -ci 3 -hf 4 -vf 4 xor

Но оно или выплевывает пустой файл (точнее, битый, с заголовками, но без тела), или один раз мне удалось заставить его работать, но он скомпилял мусор.

Для экспериментов использованы узоры XOR:

Ну и пример Леночки: https://files.catbox.moe/nawse5.jpg - 12 бит, именно ее распаковывал выше

ruzisufaka
() автор топика
Ответ на: комментарий от hobbit

Проверка на некорректные входные данные будет?

Может быть, но это не является моей целью. Сейчас я делаю редактор jpeg, что-то вроде gimp, только работающий с уже сжатыми jpeg, но это своего рода упражнения для игр с DCT/IDCT, что можно с ним вообще сделать, чтобы дальше играться уже с h264/h265/h266 (в апреле вышел даташит версии 1.0). Вот хочу понять, что я вообще смогу выжать из преобразования кодированных блоков, типа преобразования яркости/контрастности, поворота на 90 градусов или колормаппинга.

ruzisufaka
() автор топика