Чем сжимать и разжимать картинки?

Сжимать сжатое, а jpeg уже сам по себе архив сжатия с потерями, обычно бесполезно.

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

https://photutorial.com/image-format-comparison-statistics/

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

А вот MKV удастся сжать лишь перекодировкой с помощью того же ffmpeg, даже без ощутимой потери качества.

Но если ты про простую архивацию, то архивировать эти форматы бесполезно.

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

перевести в условный raw (или просто чистые данные), а потом пожать разными кодеками

Смешались в кучу кони, люди

А если серьёзно, есть форматы с потерями и без потерь, свободные и не совсем. Можно сохранить jpeg в tiff, а mp3 в wav, а потом пережать в jpeg-ls и flac, соответственно. Но зачем?

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

Есть картинки в jpg

перевести в условный raw

можно ли вытащить данные

Это умеет делать утилита djpeg.

Хотелось бы попробовать их пожать, но без потери качества.

Преобразуй в jpeg-xl, он может прозрачно пережимать старые жипеги в новый формат.

Поройся на encode.su. Там были всякие рекомпрессоры, обратимые декомпрессоры, модели для PAQ. Если не устраивать себе проблем с совместимостью, то для jpeg достаточно прогонять через mozjpeg/jpegtran или дожимать LZMA.

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

jpegtran -optimize -progressive -copy none -outfile

Есть ещё варианты более специфичные, например, некоторые особо медленные и умные архиваторы серии paq8 умеют ещё чуть-чуть поджимать jpeg-и, но тут уже не практика, а теория, потому как одна картинка будет жаться минут 5 и распаковываться минуты 3 на очень хорошей машине, но если очень хочется, то почему нет... Ну и в теории JPEG XL получше чем JPEG, но софта под него раз два и нету. Хотя, завезут т.к. gimp свежий к нему привязался, так что в новой lts ubuntu уже должен из коробки быть.

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

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

Например, у тебя несжатое видео будет например 100 000 Mб, сжатое в h264 оно же будет 200 Мб, а в gzip оно будет 70 000 Мб. Аудио лозлесс нужен разве что аудиофилам и студиям. Картинки и видео кажется вообще никто и никогда не пытается сохранить в лозлесс, потому что можно навертеть достаточное качество даже для какого-нибудь IMAX для показа в кино с лютым разрешением, фпс и качеством. Разве что гифки 100х100 пикселей с 10 кадрами могут быть без потерь.

жми нейросетями в текстовую строчку

lepton позволяет сжать jpeg (примерно на 15%-20%). После разжатия файлы побайтно идентичны.

Вроде ещё есть подобные инструменты.

PackJPG, Brunsli, jojpeg, Lepton

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

Можно оптимизировать при помощи ECT, ect -9 -strip *.jpg. В зависимости от конкретного файла, как правило, получается выиграть от 5% до 50% размера.

без потерь, но размер увеличится, а не уменьшится

У тебя устаревшая информация. Прочти то, что чуть выше написано. Этот lepton я пробовал, работает так, как написано.

https://habr.com/ru/companies/ruvds/articles/536966/comments/

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

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

Картинки и видео кажется вообще никто и никогда не пытается сохранить в лозлесс

где-то заплакал PNG

https://encode.su/threads/3233-Lossless-JPG-Compression

https://encode.su/threads/3843-Best-tools-to-compress-JPEG

jojpeg, насколько я понял, встроен в 7zip

Добавлю, что:

Видео без потери качества пережать не получится, потому что оно тоже уже пожато с потерями. Хотя иногда, если это ремукс, можно пожать с незначительными потерями — то есть с такими, что если просто смотреть видео, а не разглядывать скриншоты с лупой, разницы не заметишь. Это можно сделать с помощью ffmpeg. Но делать это может иметь смысл только если у тебя ремукс. Если уже рип (энкод), или из веба, то там уже пожато (причём если из веба, то ещё и уже мыльно).

Звук в лосслесс-форматах можно пережать с помощью flac -8. Даже если они уже сжаты им, но старой версией, то flac 1.4 и новее сожмёт чуть-чуть получше. Выиграть, впрочем, засчёт более нового флака выйдет лишь один-два процента в лучшем случае. А вот если было сжато не на восьмом уровне, тогда уже значительно.

Звук в лосси форматах (mp3, aac, ogg vorbis, opus) пережать без потери в качестве не получится, оставляй как есть или ищи лосслесс источник. Если лосслесс тебе не нужен, но нужно пожать хорошо — всё равно ищи лосслесс источник и потом жми с потерями в opus — будет выше качество и меньше размер по сравнению с mp3 или vorbis (ogg).

А, да, jpeg в jpegxl можно конвертнуть. Но тут учитывать стоит, что поддержка формата есть далеко не везде, и например браузеры в jpegxl не умеют.

ogg — это контейнер. Туда можно и кодированное opus-ом сложить.

Я в курсе, поэтому и написал чётко ogg vorbis. А так туда даже flac можно засунуть.

браузеры в jpegxl не умеют

И не надо уметь.

Компания Google представила новую открытую библиотеку jpegli с реализацией кодировщика и декодировщика изображений в формате JPEG.

https://www.opennet.ru/opennews/art.shtml?num=60921

И не надо уметь.

jpegli

Это другое. Тут надо с упомянутым мной ECT сравнивать, что эффективнее. Скорее всего, будет плюс-минус так же по размеру. Но надо побенчмаркать будет.

Хорошая табличка (2019 год).

Ran a few more compression tests using 171 jpeg image files from a HOG (Hidden Object Game). Total size of all files is 64,469,752 bytes.

Created batch files to compress each file individually.


Compressor(s)                Size(bytes) Time(seconds) Commands/Options
original files               64,469,752
7-zip                        61,284,250           7    7z a -m0=lzma2:x9
jojpeg (sh3)                 55,431,288         108    pa a -m0=jojpeg where "pa" was renamed from "7z"
jojpeg+lzma2x2               53,481,658         111    pa a -m0=jojpeg -m1=lzma2:x9 -m2=lzma2:x9:lp0:lc0:pb0 -mb00s0:1 -mb00s1:2
jojpeg+lzma2                 53,479,612         110    pa a -m0=jojpeg -m1=lzma2:x9
paq8px183fix1                52,820,938       7,511    7z a -m0=mfilter:a2 (-9)
lepton-slow-best-ratio       52,705,758         311    7z a -m0=mfilter:a1
brunsli                      52,444,562          20    7a a -m0=mfilter:a0
precomp+paq8px183fix1        52,011,550      13,480    precomp047 -cn -intense + paq8px v183fix1 -9
precomp+paq8px183fix1        52,011,220                precomp047 -cn -intense + paq8px v183fix1 -9beta
packjpg (version 2.5k)       51,975,698          39
fast paq8 (version 6)        51,588,301         623    -8
paq8px183fix1+lzma2          51,434,256       7,468    7z a -m0=mfilter:a2 -m1=lzma2:x9 (-9)
precomp048dev                51,427,935          23    precomp048dev -cl -intense
paq8pxdv69                   51,365,725       7,753    -s9
reflate+paq8px183fix1        51,351,145       7,966    arc a -m0=reflate + paq8px183fix1 -9
pzlib+paq8px183fix1          51,314,381       7,827    paq8px183fix1 -9
paq8px183fix1                51,310,086       8,021    -9
brunsli+lzma2                51,133,547          24    7z a -m0=mfilter:a0 -m1=lzma2:x9
lepton-slow-best-ratio       51,131,392          49
lepton+lzma2+paq8px183fix1   51,119,130         422    7a a -m0=mfilter:a1 -m1=lzma2:x9 -m2=mfilter:a2 (-9)
lepton+lzma2                 51,116,016         298    7z a -m0=mfilter:a1 -m1=lzma2:x9
precomp048+paq8px183fix1     51,068,700      13,835    precomp048dev -cn -intense + paq8px183fix1 -9
lepton+paq8pxdv69            50,835,719      14,941    7z a -m0=mfilter:a1 + paq8pxd69 -s10
lepton+paq8pxdv69            50,835,708      14,858    7z a -m0=mfilter:a1 + paq8pxd69 -s9
lepton+paq8px183fix1         50,782,720      14,149    7z a -m0=mfilter:a1 + paq8px183fix1 -9
lepton+srep+paq8px183fix1    50,768,509                lepton-slow-best-ratio + srep(v3.93) -a1 + paq8px183fix1 -9
lepton+paq8px183fix1         50,747,070                lepton-slow-best-ratio + paq8px183fix1 -9beta; VERY slow

Noticed that packjpg tended to produce larger than original files when compressing small files originally in the tens of kilobytes size. But packjpg performed better with good compression on larger files in the 100's of kilobytes size and up.

Но делать это может иметь смысл только если у тебя ремукс

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

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

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

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

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

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

В теории да. И в бóльшем разрешении при этом. На практике — не всегда — потому иногда и получаем голимый апскейл в виде релиза на блюрее. Тут как с исходниками ресурсов и кода игр, когда ремастеры выпускать хочется, они тоже по идее хранятся в теории. И в большинстве случаев они есть, но не во всех. На практике студии иногда друг друга покупают-продают (или не друг друга, а только права на франшизы), распускают команды и собирают новые, пролюбливают все полимеры и т.д. и т.п. Ну и некоторые мелкие студии могут изначально не сохранять в высоком качестве/разрешении.

Прошу прощения у всех за офтоп, но рядом на этом же ресурсе сравнение сгенерированных несколькими ИИ-ми картинок по нескольким темам. Наглядны ограничения.
https://photutorial.com/best-ai-image-generators/

ЗЫЖ Соврал капче. Это нормально?

https://ieeexplore.ieee.org/document/10125564

Haohan Li; Zhaoyi Sun; Jie Sun

Invert-and-project (IVP): A Lossless Compression Method of Multi-scale JPEG Images via DCT Coefficients Prediction

Published in: 2023 Data Compression Conference (DCC)

Abstract:
JPEG is a widely used format for images. Most JPEG variants are based upon a block-based DCT transformation followed by quantization and entropy coding. Redundancy at row/column level is explored in [1]. Brunsli [2] and Lepton [3], lossless JPEG repacking libraries, explore redundancy at block level.

Почитаю на досуге источники, буду пробовать колдовать.

Пока читал комментарии, возник довольно нубовский вопрос: а что собственно внутри JPEG с точки зрения кодека\ОС? Массив из пикселей, математические формулы или.. каким-то образом преобразованные (пережатые) сигналы с матрицы фотоаппарата? Также, JPEG, MP3 - архивы, контейнеры, что-то ещё?

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

Отсюда вытекает и второй вопрос. Как пользователю понять, что файл пожался без потерь или с потерями? Ну, скажем, пережал я JPEG в PNG напрямую, где гарантия, что из картинки действительно ничего не выкинули? Или если я получил из картинки «чистые данные» (декомпрессия JPEG?), а потом пожал в PNG Размер, собственно, полезных данных внутри PNG, побайтово, будет одинаковый или разный? И почему.

А фильмы ведь где-то в таком виде хранятся у студий: не сжатом

Стандарты DCI

Согласно этому стандарту, исходные изображения каждого кадрика формата TIFF при сохранении сжимаются по стандарту JPEG 2000, используя цветовое пространство CIE XYZ с глубиной цвета 12 бит на канал. При этом, в отличие от технологии HDTV, использующей полное сохранение только «ключевых» кадров, стандарты DCI предусматривают равноценную запись каждого кадра кинофильма.

Ну, скажем, пережал я JPEG в PNG напрямую, где гарантия, что из картинки действительно ничего не выкинули?

Смотря с какими параметрами JPEG и с какими PNG. Если ты JPEG 1024x768 пережал в PNG 320х200 - потери неизбежны.

lepton позволяет сжать jpeg (примерно на 15%-20%). После разжатия файлы побайтно идентичны.

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

Пушечно. Стоило бы эту фичу в сам формат файла добавить.

Про математику в преобразовании https://www.youtube.com/watch?v=eQlSvfUuQNs

Как пользователю понять, что файл пожался без потерь или с потерями?

В случае с картинкой сконвертировать всё в BMP и сравнить побайтово. Наверно. Не проверял. То есть сравнить каждый пиксель.

Ну, скажем, пережал я JPEG в PNG напрямую, где гарантия, что из картинки действительно ничего не выкинули? Или если я получил из картинки «чистые данные» (декомпрессия JPEG?)

То, что уже выкинуто JPEGом, не вернуть.

а что собственно внутри JPEG с точки зрения кодека

коэффициенты, полученные из быстрого преобразования Фурье

JPEG уже с потерей качества, поэтому постановка вопроса изначально некорректная. Вот PNG без потерь.

В принципе, то же относится и к видео, аудио

И для видео, и для аудио есть lossy- и lossless-кодеки. Для видео lossless применяется редко, но в природе существует (HUFFYUV, например). А для аудио сжатие без потерь применяется довольно широко (FLAC, WavPack, APE).

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

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

Тут можно вспомнить про файловую систему и размер кластера ;) Сжать оптом много-много мелких картинок таки ж может иметь смысл.

Меня удивляет, кстати. В 2016 году было опубликовано. И до сих пор многие считают, что jpeg не сжимаем (в смысле без потерь). Кроме меня про lepton на лоре никто и не упоминает, вроде.

Может уж гул с jpegli продвинет аналогичное (и будут в интернетах новые джепеги, старым софтом не показываемые?)

Внутри картинок пиксели, в зависимости от глубины цвета сколько-то бит на пиксель, например 24 (по 8 на красный, зелёный, синий). Внутри аудио сэмплы, тоже сколько-то бит, например 16, например 44100 выборок в секунду. Все кодеры/декодеры (сокращённо ко/деки) пакуют из несжатых данных в сжатые и обратно, иначе как эти картинки ещё посмотреть.

Lepton

https://github.com/dropbox/lepton

This repository has been archived by the owner on Feb 14, 2023. It is now read-only.

If you would like to continue using Lepton, please check out Microsoft’s implementation of Lepton in Rust or alternatively consider switching to other lossless compression methods such as Brotli or to modern image formats such as WebP or JPEG XL.

Ну вот, опять он/они. :)

switching to other lossless compression methods such as Brotli

Мутят воду, гады. Для jpeg other — Brunsli

https://github.com/google/brunsli

Brunsli allows for a 22% decrease in file size while allowing the original JPEG to be recovered byte-by-byte.

.bmp вообще без компрессии. .png сжимает без потерь. Архиватор zpaq умеет хоть как то жать сжатое мультимедиа, на целых пару процентов против увеличения размера у остальных.

Меня удивляет, кстати. В 2016 году было опубликовано. И до сих пор многие считают, что jpeg не сжимаем (в смысле без потерь).

Я и после ознакомления с этим алгоритмом так считаю, если речь идёт про практическое применение. Сжатие - это не выиграть какие-то жалкие проценты с помощью малоподдерживаемого алгоритма. Вот если б он в 2 раза сжимал уже можно было б подумать.

«на целых пару процентов», на 20%, всё тлен, согласен.

Ну тут не только арифметическое кодирование... Много чего в jpeg-е не учли когда его делали, например, то что большая часть картинки это тупо градиенты с некоторыми флуктуациями...

jpegtran по сути тоже самое делает, даже формат не меняет на выходе всё тот же жипег. Я писал выше почему не добавили - сохранение картинки относительно ресурсоёмко

В случае с картинкой сконвертировать всё в BMP и сравнить побайтово. Наверно. Не проверял. То есть сравнить каждый пиксель.

там у imagemagick-а есть такая фича,

magick compare rose.jpg reconstruct.jpg difference.png

Вот PNG без потерь

Показать тебе PNG с потерями качества?

Без потерь разве что исходный RAW, формат PNG не означает что это эталон качества.

Без потерь разве что исходный RAW

ТС написал «картинки», вообще-то. А картинки это совсем необязательно что-то с фотоаппарата.

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

Я тебе в личку отправил картинку. Использовал сжатие с потерями.

Что ты потерял?

JPEG уже с потерей качества, поэтому постановка вопроса изначально некорректная.

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