Pull to refresh

Comments 29

Кажется, нет смысла приводить полотнища исходников, если есть ссылка на гитхаб.
Статья выглядит отталкивающе из-за своих объёмов :)
А по сути интересно, спасибо.
Была уже хорошая статья по этому алгоритму, правда картинки к ней не сохранились.
habrahabr.ru/post/48518/
Задача актуальна.
На сколько сильно ест процессор?
А есть что-то такое для image magick?
Загружает процессор сильно, так как использовано динамическое программирование. Было бы интересно вместо него использовать какой-то вероятностный алгоритм поиска локального минимума, который бы работал при этом намного быстрее.
Полезно показать гифку, как изменяется размер скажем от 500*500 до 300*400 пикселей.
В динамике хорошо видно как это происходит — за счет чего изображение сжимается.
Еще можно упомянуть, что в фотошопе это называется 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"
А если вместо довольно сложного «Seam» метода просто придать веса значимости пикселям как функцию от энергии, и использовать один из стандартных методов масштабирования с учётом этих весов?
В статье есть сравнение результатов в этим подходом.
Хорошо бы для наглядности рядом две картинки: первая — обычное сжатие, второе — seam carving одного размера. А то на фото сверху — ну сжали и сжали, paint так тоже может, кажется :-)
Здесь может быть и увеличение. Речь идет об изменении aspect ratio, так что части изображения сохраняют неискаженный вид.
Меньше неба, больше суши, рисунки на песке остались той же формы.
Спасибо за проделанную работу. Очень интересно.
Однако, у меня есть два коварных и неприятных вопроса :)

1. Почему у вас энергия — это мера информации? Энергия — это без сомнения информация с философской точки зрения, но ее мера — это обычно энтропия.

2. Почему вы называете свой критерий «энергией»? Приведенная функция пропорциональна норме вектора градиента. Я бы ее скорее назвал частотой. Во всяком случае, на частоту данный параметр похож куда больше, чем на энергию или энтропию.

PS: Это не попытка докопаться :) Мне действительно интересно, почему так. И я буду очень рад, если смогу разобраться в вашей логике, даже если окажусь где-то не прав :)
UFO landed and left these words here
Это не я. Это авторы статьи. Вообще, в computer vision часто называют вещи терминами из физики. Видимо, люди которые работают по этой теме пришли из этой области. Можете попробовать, кстати, другие варианты подсчета энергии и посмотреть что получится.
Возможно это не из-за алгоритма, но из достаточно четкой картинки на выходе получилось мыло
На самом деле не все так просто. На многих изображениях поиск минимальной энергии находит совсем не те участки. Например, человек (желательно в какой-нибудь однотонной одежде) на фоне кустов.
Да, я знаю. В этом случае надо помечать более важные пискели в ручную. Либо, если есть информация о глубине — например с Kinect — то можно усложнить функцию придавая более близким объектам большую энергию, нежели более удаленным.
Получается, при довольно сильном уменьшении перспектива может исказиться — картинка уменьшится, а человечки останутся прежними.
Видео с примером работы (может, кому-то интересно будет):
Было интересно, спасибо. :)
В свое время писал курсач по этой теме
Я понимаю суть алгоритма, и знаю, что по другому не могло быть, может я не оригинален, но почему человек на последнем фото держит оторванную руку?
Может потому что Япония?

Only those users with full accounts are able to leave comments. Log in, please.