Привести jpeg к определенному размеру файла

в принципе изменяя степень сжатия или используя постиризацию и другие оптимизации

Включи галку предпросмотра при сохранении из гимпа.

Я имею ввиду, автоматически - я сказал размер, указал файл - получил на выходе результат.

Кодируй в два прохода.

Поясни.

Он показывает в килобайтах, а мне нужно в байтах. Настроить это никак.

convert in.jpg -resize 'widthxheight' out.jpg

где widthxheight - определяет размер файла

А может быть widthxheight - это новые ширинаХвысота, а не желаемый размер целевого файла?

Для convert можно выставить максимальный: -define jpeg:extent=400kb, по идее можно и точный сделать, добавив мусора, но хотелка странная.

Есть jpeg-картинка. Нужно как-то ее изменить, чтобы размер
результирующего jpg-файла был N байт, то есть, привести
картинку к определенному размеру ФАЙЛА. Такое можно сделать?

Можно. Сохранить с минимальным качеством и добить байтами в конце до нужного размера.

You asked for it, you got it.

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

Можно еще статистики набить (зависимость размера файла от качества), чтобы интерполяцию делать поточнее.

Размер с точностью до байта сильно сомневаюсь что можно сделать. Можно сделать с определенной погрешностью. Такой функционал есть у phatch. Поковыряй исходник

Да, я уже понял, спасибо.

С точностью до байта МОжНО сделать - анон выше написал.

Можно еще статистики набить (зависимость размера файла от качества), чтобы интерполяцию делать поточнее.

Всё равно лажа будет. Потому что файлы с разным количеством и насыщенностью цветов и разным количеством деталей жмутся очень по-разному.

Знаю, но общая тенденцию вполне может быть (например, логарифмическая зависимость или степенная...)

И что? Здравый смысл подсказывает, что зависимость монотонная, так что дихотомия должна помочь, разве не так?

Знаю, но общая тенденцию вполне может быть (например, логарифмическая зависимость или степенная...)

А вот ни фига, в том-то и дело. Зависимость-то общая, но она из нескольких компонент состоит, и значения параметров у этих компонент будут от файла к файлу сильно различаться.

Здравый смысл подсказывает, что зависимость монотонная

Кому? Мне - наоборот.

По-моему, зависимость должна быть степенной.

Т.е. размер файла при увеличении ширины/высоты и неизменными осталными параметрами может внезапно уменьшиться? Да ну?

Да ладно: хотя бы общие тенденции если выявить, то все быстрее будет (например, вместо деления отрезка пополам, делить его в пропорции 2:3).

при увеличении ширины/высоты и неизменными осталными параметрами

А кто говорит о такой процедуре?

Да вариантов-то два:

менять размеры

менять «качество»

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

Ясен пень, что монотонная. Но не линейная, а какая-то другая.

Вот пример зависимости размера файла (в байтах) от качества сжатия. Сделал 100 картинок (со скриншота в png).

А вот этот график получился при сжатии предыдущего графика.

кусок скрипта:

BASENAME=`echo $1 | sed -e "s/\..*//"`
OUTNAME=${BASENAME}-web.jpg
FILESIZE=200000

# prepare JPEG

QUALITY=99

while true;
do
        echo "Making JPEG Quality $QUALITY"
        convert $1 -quality $QUALITY $OUTNAME
        jhead -du $OUTNAME
        SIZE=`du -s -b $OUTNAME | awk '{ print $1 }'`
        echo $SIZE
        if [ $SIZE -lt $FILESIZE ] 
        then 
                break;
        fi
        QUALITY=$[$QUALITY-1]
done

Упс, «проседания» возникли из-за того, что я забыл переименовать файлы x.jpg -> 0x.jpg. Вот правильный график.

Вот функция для получения таблицы:

 
function mkjpegs(){ for Q in $(seq 1 100); do NAME=$(printf '%03d' $Q); convert $1 -quality $Q $NAME.jpg; done; du -b *jpg| awk '{print $1}'>sizes; rm -f *jpg; }

Чтобы построить, запускаем gnuplot и пишем plot 'sizes' w l

Можно для оптимизации не по одному вычитать, а делить интервал пополам :)

зависит от размеров. Если ожидается ответ близкий к 100, то выгоднее так

А вот этот график получился при сжатии предыдущего графика.

Ха! keewl

Хотя объяснимо. Какое сжатие используется в jpeg?

Чорд, я уже гипотезы начал строить.

Ага, я тоже сначала глянул на график, вспомнил о БПФ и без задней мысли отправил его. А потом вспомнил, что производительность БПФ никакой связи со сжатием jpg не имеет :)

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

Здравый смысл не понимает, нафига нужна такая процедура. А вот с качеством уже понятнее.

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

Ровно то, о чём я говорил, получилось. На взгляд - три компоненты, и параметры на втором скриншоте сильно отличаются. Предсказать размер очень затруднительно.

У меня нет скачка на 90% http://imageshack.us/f/832/68611117.png/

for ((i=0;i<=100;i++)); do n=`printf %03i $i`.jpg; cjpeg -quality $i a.ppm >$n 2>&-; echo -ne $i' '; stat -c %s $n; done | graph -T X -