Отрезаем голову в nginx

[@imater]

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

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

[@JustRoo]

отличать лицо от попы

С этим я не всегда справляюсь, а вы хотите скрипт научить.

[@KOLANICH]

OpenCV, каскад Хаара, модуль к нгинксу, не?

p.s. 100% вероятности, как вы уже заметили, даже человек не даст ;)

[@psman]

Для ряда сайтов определять — важный функционал, И в зависимости от категории картинки показывать лицо или…

[@ezotrank]

Не, nginx — это хорошо, но скалинг изображений ИМХО не должен ложиться на плечи веб сервера.

[@kamiram]

есть, кстати, чуйство, что воркер при таких операциях затыкается.

[@bobrik]

Вы же не думаете, что nginx для ресайзинга картинок держит миллион соединений? :)

[@garex]

Это же кроп. А вот х.з. — в бэкграунд отправлять на демона какого? А если нам та картинка не нужна?

Было уже что-то подобное на хабре — пришли к выводу, что зависит от условий.

Есть много диска и не жалко проц — делаем заранее. Надо более гибко? Режем в прямом эфире.

[@kliss]

Я вот не понял, а зачем каждый раз при отдаче нарезать? Не проще ли нарезать один раз при заливке?

[@bobrik]

После нарезки картинка кладётся в кеш, это далеко не «каждый раз нарезать». Если нарезать при заливке, то однажды наступит ситуация, когда нужно будет нарезать ещё один размер для 200 миллионов картинок.

[@kliss]

А, ну тогда ладно )

[@MaxxArts]

А как часто возникает ситуация, когда нужно нарезать еще один размер?
И даже если это происходит каждую неделю, почему нельзя нарезать «лениво»? Ну то есть, вот пришел запрос, нарезали и положили (раз уж для вас нарезать на лету вполне приемлемо). Неужели места жалко?

[@bobrik]

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

[@MaxxArts]

Кеш это понятно. Я имею в виду, почему нельзя класть на диск, а в следующий раз брать (и класть в кеш) уже с диска вместо нарезания снова. Вы замеряли, сколько занимает нарезка фотки и как часто протухает кеш? И каков, кстати, процент попадания в кеш?

[@bobrik]

Ну смотрите, картинка 5 мегабайт, нарезанные копии по 20кб x 5 штук. Итого в ясную погоду 5 скачков (это ещё без метаданных) по диску. Ежели оставить только 5 мегабайт, то остаётся одно чтение (для нарезки чтения будут из кеша) + cpu. Окружающая ситуация такова, что cpu гораздо дешевле disk seek. Нарезка фотки занимает гораздо меньше времени, чем поднятие фотки с диска.

[@MaxxArts]

Нарезка фотки занимает гораздо меньше времени, чем поднятие фотки с диска.

Да, если не считать, что нарезка фотки включает в себя поднятие с диска оригинала фотки. То есть, в случае нарезки это время поднятия + время нарезки. В случае с уже нарезанным файлом, это только время поднятия с диска. При чем поднять 5 МБ или 20 КБ тоже разница есть.

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

[@bobrik]

5 мегабайт поднимается один раз, потом он берётся из кеша. Линейное и рандомное чтение — две большие разницы, прочитать подряд 5 мегабайт проще, чем три раза по 20кб.

[@MaxxArts]

5 мегабайт поднимается один раз, потом он берётся из кеша

Что это за кеш такой интересный, что 5МБ фотка туда кладется, а ее ресайз в 20КБ нет?

Линейное и рандомное чтение — две большие разницы, прочитать подряд 5 мегабайт проще, чем три раза по 20кб.

Как вы гарантируете, что ваши 5МБ не фрагментированы и читаются последовательно? И зачем читать три раза по 20КБ?

Мы, видимо, немного о разном говорим )

[@bobrik]

Линейность записи фотки гарантируется сервером, который эту фотку у себя держит.

Ресайз фотки кладётся в кеш, но чтобы его туда положить, нужно сначала с диска прочитать. Если мы ресайзим на лету, то после первого чтения оригинальных 5 мегабайт, они лягут в кеш уровня сервера данных. Ресайзы лягут кеш, который выше ресайзеров. При пустом кеше три размера получаются как одно чтение с диска 5мб + 2 чтения из кеша + 3 ресайза.

В вашем варианте при пустом кеше три размера получаются как 3 чтения с диска.

[@MaxxArts]

Понятно, у вас хранилище а-ля FB Haystack. А если не секрет, все же, сколько времени занимает ресайз фотки в вашем случае и чтение фотки из вашего хранилища? Наверняка же какие-то тесты делали.

[@bobrik]

Прямо сейчас ресайз + чтение в среднем 66ms, чтение с диска 15ms.

[@MaxxArts]

То есть, чистый ресайз ≈ 50 мс, или чтение из 66 мс это не с диска?

[@bobrik]

Чистый ресайз + сеть 50ms, именно так.

[@MaxxArts]

Тогда о чем был комментарий выше — Нарезка фотки занимает гораздо меньше времени, чем поднятие фотки с диска.?

[@bobrik]

Дело в объёмах, если с диска поднимать больше, то и работать будет медленнее.

[@MaxxArts]

Ок, пики у вас вечером, как и у всех, я полагаю. Можете указать время для пиковых нагрузок?

Мы просто как-то очень давно замеряли время нарезания nginx'ом фоток на лету, и результаты были какими-то неприличными. Я, правда, не уверен, что резали тем же самым модулем.

[@FB3]

Это если 5 мегабайт не фрагментированы по диску :)

[@ToSHiC]

Мы так делаем, у нас работает хорошо. Почти 20млрд картинок, если считать вместе с ресайзнутыми, всего на 6 машинках, в трёх копиях. Размеров штук по 6 на каждую картинку + при заливке пытаемся детектить лица и вырезать тот кусок, где лицо. Не получилось — ну тогда просто ресайз с, возможно, кропом, чтобы в квадратик вписать (не для всех размеров).

[@s1dney]

Одно непонятно: как вы узнаете какой параметр передавать image_filter_offset в nginx, чтобы получилось лицо?

[@bobrik]

Мы делаем допущение, что лицо у людей растёт на голове, которая сверху. image_filter offset center top; у нас :)

[@s1dney]

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

[@bobrik]

Люди могут загрузить 100 фотографий и не захотеть выбирать, где у них там по^W лицо, а превьюшки показывать нужно, вот и приходится вставлять разного рода подпорки.

Но вообще предлагать выбрать важные части тела при загрузке правильно, тут не поспоришь.

[@s1dney]

Странное решение, если честно. Какой % от всех картинок такой механизм обрабатывает не так, как хотелось бы? Почему просто не делать это на кеширующем бэкэнде с уверенностью, что «тут лицо, а тут попа»?

[@Agent_Smith]

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

[@savant]

«Лучший вариант это дать юзеру возможность самостоятельно отрезать себе голову»

Так гораздо лучше.

[@vvzvlad]

Ну, это просто. Стрелять в ноуг научились же как-то.

[@FloppyFormator]

Говоря простым языком, торец украшает переднюю часть бубна.

[@savostin]

Так а что если фотка таки горизонтальная и еще оно там лежит? Тут точно нет гарантии, что лежит слева направо, а не наоборот. Или вообще не лежит, а широко улыбается ;)

[@shevgeny]

О чем автор говорит — о сайте знакомств. А такое впечатление, что никогда там не бывал! Посмотрите на фото девчонок там, какие там фотки? Большинство девчонок либо на скамейках, либо на кроватях, либо на пляже. И они там лежат. И фото там горизонтальные. И лица то справа, то слева. А в центре фото — хм… хотя нет, автор явно бывал на сайтах знакомств и знает что обрезать! :)

[@docomo]

Именно поэтому все современные сайты с профайлами дают возможность самому выбрать область изображения для превьюхи.
Автор же пытается решать гуманитарные проблемы техническим путем. Увы, результат такого решения почти всегда так себе.

[@MaxxArts]

Когда-то что-то слышал про Topface и думал, что уж вот у кого самые крутые методы определения лица на фотографиях должны быть. А после прочтения поста — *facepalm*

[@bobrik]

Игорю Шпизелю привет передавайте! :)

[@MaxxArts]

Очень конструктивный комментарий. Серьезно, почему бы не определять лицо на фотке? Алгоритмов масса, все давно изучено.

[@pomme]

OpenCV + несложная флеш-модерилка дают прекрасный результат.
Попробуйте, это в самом деле несложно.

[@n0ne]

Могу ошибаться, но если это превьюшка фотки, то сервер не должен иметь права сам решать, что ему обрезать. Сервер имеет право только уменьшить оригинал до заданных размеров превьюшки. И не важно, как там на фотке расположено изображение, вытянуто вертикально или горизонтально. Превьюшка должна быть уменьшена пропорционально до требуемых размеров, например, 200х200px. Либо позволить пользователю самому задавать часть фотки, из которой делается превьюха, благо это сделать совсем не сложно.

[@pomme]

Особенно вдохновляют примеры картинок.

У вас на сайте в рейтинге фото лидируют длиннокот, лыжница без головы и замороженная капуста? о_0

[@pomme]

Напишите в партнерку Мамбы, отсыпем вам красивых девушек.

[@invite]

Раз появилась такая тема, тоже подниму вопрос рациональности такого ресайза, операции io должны быть дешевле, судя по текущим ценам на рынке, по этому возвращаюсь к вопросу по презентации «node.js for millions of images», уже задавал, но так и не получил ответа

«А что за диски использовались/используются sata, sas, ssd, какого объема один диск, в каком raid-массиве они собраны и используется ли lvm?»

[@bobrik]

SATA 1Tb, один диск под один логический сервер со своим куском данных, без raid и lvm.

Операции io дешевле чем cpu? Не путаете с объёмами дисков? :)

[@invite]

Посмотрите на raid10, я бы предложил raid6, производительность выше, но проблем с ним бывает намного больше http://ru.wikipedia.org/wiki/RAID#RAID_10, при этом по возможности собирать это из дисков 500gb, потому, как я понял, вам не хватает IOPS, а на один диск выдает определенное кол-во, вне зависимости от объема.

По поводу цены, смотрите, процессор такое дело, максимальная тактовую частота находится на определенное границе и рост пока не ожидается, а из дисков могут собирать вполне производительные san'ы, вот пример. Сравнивать 8 ядерные Xeon'ы c даже 500gb SAS, думаю, нет необходимости

[@invite]

И сразу еще один вопрос, почему не заюзать сторонний CDN для картинок?

[@Mr_Floppy]

Лица можно находить с помощью OpenCV буквально за 3 строчки:
cascade = cv2.CascadeClassifier()
cascade.load('/opencv/data/haarcascades/haarcascade_frontalface_alt.xml')
faces = cascade.detectMultiScale(img)

[@sn00p]

Вот тут можно определить голову кота, например. Правда слишком медленно.

[@akalend]

оно и должно быть медленно… быстро только блохи прыгают…

[@ofiginuri]

s1.hostingkartinok.com/uploads/images/2012/11/3f870bec126c8ecdd7073c9b1a789e1d.png

[@akalend]

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

[@garex]

Коммент на гитхабе доставляет:

en: Humans usually have faces at the top of their photos

ru: Люди обычно имеют лица в верху их фото

Балин… Че к чему nginx ещё не на гитхабе (мирор не в счет)? Так бы можно было этот модуль форкнуть и запулреквестить, чтобы в основной веточке появилось.

Попробуйте связаться с тов. Дуниным, чтобы сюда замерджить:
trac.nginx.org/nginx/browser/nginx/trunk/src/http/modules/ngx_http_image_filter_module.c

ps: Коммент кинул на гитхабе: github.com/bobrik/nginx_image_filter/commit/bf6535355f508abbdab25cc719fdbe7aa7715cb7

[@bobrik]

Тикет в trac nginx.

За коммент спасибо, вечером поправлю :)

[@garex]

Для красоты ещё можно whitespace сделать таким же, как в исходной версии, чтобы пир diff`е не обращать на него внимания.

[@bobrik]

Они вроде как такие же