Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 29
Кажется, нет смысла приводить полотнища исходников, если есть ссылка на гитхаб.
Статья выглядит отталкивающе из-за своих объёмов :)
А по сути интересно, спасибо.
Статья выглядит отталкивающе из-за своих объёмов :)
А по сути интересно, спасибо.
Была уже хорошая статья по этому алгоритму, правда картинки к ней не сохранились.
habrahabr.ru/post/48518/
habrahabr.ru/post/48518/
И с картинками есть!
восстановил большинство картинок в исходной статьи.
Задача актуальна.
На сколько сильно ест процессор?
А есть что-то такое для image magick?
На сколько сильно ест процессор?
А есть что-то такое для image magick?
Другое название liquid scaling. Для PHP php.net/manual/en/imagick.liquidrescaleimage.php, необходима liblqr для ImageMagick, другими словами решение видимо существует.
Например: vm-0.jmas.koding.kd.io/150p.jpg в vm-0.jmas.koding.kd.io/150p2.jpg
Командой:
Командой:
convert 150p.jpg -liquid-rescale 40x100%\! 150p2.jpg
ImageMagick — www.imagemagick.org/Usage/resize/#liquid-rescale
Загружает процессор сильно, так как использовано динамическое программирование. Было бы интересно вместо него использовать какой-то вероятностный алгоритм поиска локального минимума, который бы работал при этом намного быстрее.
Полезно показать гифку, как изменяется размер скажем от 500*500 до 300*400 пикселей.
В динамике хорошо видно как это происходит — за счет чего изображение сжимается.
Еще можно упомянуть, что в фотошопе это называется Content-Aware Scale. В гимпе тоже есть.
В динамике хорошо видно как это происходит — за счет чего изображение сжимается.
Еще можно упомянуть, что в фотошопе это называется Content-Aware Scale. В гимпе тоже есть.
В ImageMagick называется Liquid Scale.
Тоже стало интересно посмотреть анимацию.
jMas, спасибо за imagemagick, не знал что он так умеет.
Kirill_Lykov, можете добавить мой gif в статью.
Сделай сам [:|||:]
#!/bin/bash
for i in {100..005..5}
do
echo "Frame width $i"
convert "original.jpg" -liquid-rescale "${i}x100%" "scaled/$i.png"
convert "scaled/$i.png" -resize "x240" "frames/$i.png"
done
echo "Making gif..."
convert -delay 40 -dispose 2 "frames/*.png" \
-reverse "frames/*.png" -loop 0 "animate.gif"
for i in {100..005..5}
do
echo "Frame width $i"
convert "original.jpg" -liquid-rescale "${i}x100%" "scaled/$i.png"
convert "scaled/$i.png" -resize "x240" "frames/$i.png"
done
echo "Making gif..."
convert -delay 40 -dispose 2 "frames/*.png" \
-reverse "frames/*.png" -loop 0 "animate.gif"
А если вместо довольно сложного «Seam» метода просто придать веса значимости пикселям как функцию от энергии, и использовать один из стандартных методов масштабирования с учётом этих весов?
Хорошо бы для наглядности рядом две картинки: первая — обычное сжатие, второе — seam carving одного размера. А то на фото сверху — ну сжали и сжали, paint так тоже может, кажется :-)
Спасибо за проделанную работу. Очень интересно.
Однако, у меня есть два коварных и неприятных вопроса :)
1. Почему у вас энергия — это мера информации? Энергия — это без сомнения информация с философской точки зрения, но ее мера — это обычно энтропия.
2. Почему вы называете свой критерий «энергией»? Приведенная функция пропорциональна норме вектора градиента. Я бы ее скорее назвал частотой. Во всяком случае, на частоту данный параметр похож куда больше, чем на энергию или энтропию.
PS: Это не попытка докопаться :) Мне действительно интересно, почему так. И я буду очень рад, если смогу разобраться в вашей логике, даже если окажусь где-то не прав :)
Однако, у меня есть два коварных и неприятных вопроса :)
1. Почему у вас энергия — это мера информации? Энергия — это без сомнения информация с философской точки зрения, но ее мера — это обычно энтропия.
2. Почему вы называете свой критерий «энергией»? Приведенная функция пропорциональна норме вектора градиента. Я бы ее скорее назвал частотой. Во всяком случае, на частоту данный параметр похож куда больше, чем на энергию или энтропию.
PS: Это не попытка докопаться :) Мне действительно интересно, почему так. И я буду очень рад, если смогу разобраться в вашей логике, даже если окажусь где-то не прав :)
Возможно это не из-за алгоритма, но из достаточно четкой картинки на выходе получилось мыло
На самом деле не все так просто. На многих изображениях поиск минимальной энергии находит совсем не те участки. Например, человек (желательно в какой-нибудь однотонной одежде) на фоне кустов.
Этот алгоритм был темой одного из практических заданий в курсе Algorithms, Part II. Одно из моих любимых заданий.
Получается, при довольно сильном уменьшении перспектива может исказиться — картинка уменьшится, а человечки останутся прежними.
Видео с примером работы (может, кому-то интересно будет):
В свое время писал курсач по этой теме
Я понимаю суть алгоритма, и знаю, что по другому не могло быть, может я не оригинален, но почему человек на последнем фото держит оторванную руку?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Алгоритм seam carving для изменения размера изображения