Есть 2 метода поиска по гифкам - по первому кадру с гифки, и по всем / баянометр

баянометр 
Есть 2 метода поиска по гифкам - по первому кадру с гифки, и по всем
На сколько важен полнокадровый поиск? И стоит ли его вообще реализовывать на новом языке

Подробнее
баянометр
Нужен ли поиск по каждому кадру гифок?
Обязательно
1239 (43.5%)
Достаточно будет по первому кадру
528 (18.5%)
Насрать
724 (25.4%)
Нахер гифки
359 (12.6%)
Еще на тему
Развернуть
смотря как по всем кадрам будет организован поиск, есть же еще и нарезки с нескольких гифок
artcher artcher 17.06.201721:39 ответить ссылка 5.6
Это значит берется КАЖДЫЙ кадр из гифки, после получается хеш каждого кадра, практически одинаковые кадры убираются, на случай, если там гифка в 100 кадров, а там просто кот в одной позе срет, и по оставшимся идет поиск
ExtraDJ ExtraDJ 17.06.201721:40 ответить ссылка 11.7
какой ты хеш берешь?
viteo viteo 17.06.201721:52 ответить ссылка 0.5
Читай что такое pHash. У него правда есть куча проблем, но танцевал я от него
Хеш срущего кота, очевидно же.
AshB AshB 17.06.201723:11 ответить ссылка 5.3
Срущего кота по разному можно хешировать.
Можно pHash-м, а можно и извлеченные resnet-м фичи приюзать (правда, это больше подойдёт для других целей, а не для баянометра)
А можно ссылку на срущего кота?
Ничего интересно, там всего 100 кадров, и все одинаковые.
dstwo dstwo 18.06.201700:37 ответить ссылка 1.6
думаю для больших гифок подойдет вариант проверки каждого 10-20 кадра.
TaiGel TaiGel 18.06.201706:10 ответить ссылка 1.9
так вот в чем разница
нынешний только первый кадр проверяет, а прошлый по всем смотрел?
я за улучшенный поиск, но
как сильно скажется на времени поиска и нагрузке разница между вариантами? не сильно ли мы ушатаем сервак поиском гифок по всем кадрам?
Ну если там будет 100 совершенно разных кадров, то и нагрузка будет в 100 раз больше)
энд вот эбаут гифки по 100мб?
Хуево. Как минимум потому что такая гифка будет грузиться на сервер 15 секунд в лучшем случаи
ЕМНИП, кстати, этот наш JS же позволяет парсить на клиенте.
Средствами filesystemapi и чего-то типа https://github.com/buzzfeed/libgif-js
Подгрузка гифки в 100 метров в какую либо переменную убивает любой браузер. Комфортный придел - 10Mb. Для слабеньких ноутов и того меньше
А делал кто-то сравнение на сколько полнокадровый затратнее по ресурсом и на сколько точнее? В том варианте что был гифки редко находились баянистые. Хотя я не особо много их грузил. Может у кого-то больше опыта с этим вопросом.
И может делать сравнение по количеству кадров в гифке (если количество кадров не совпадает, то гифка может и видоизменненая, но другая), первому, последнему и, скажем, среднему кадру какому-то кадру?
Это только усложнит поиск
то есть если два чувака взяли одно видео и обрезали из него ключевой момент, но с разницей в 1 секунду, то это типа уже не баян по твоему?
Нет. Я говорю о том, что куда сложнее в поиске учитывать еще и количество кадров
Баян конечно, но если б так было проще реализовать, то был бы выход. Если б эти 2 чувака обрезали что-то то скорее всего и количество кадров было различным. Кстати сказать, в покадровом сравнении тоже баян ведь пройдет если скажем к оригинальной гифке вконце прилепили какую-то фиговину.
Ты не понял в чем суть. Проверяется не соответсвие каждому кадру, а примерное совпадение каждого кадра.
К примеру у нас есть 2 гифки. Первая 10 кадров из фильма, вторая 30 кадров, 10 из которых точно повторяют первую
Это не будет считаться баяном. Другая ситуация. У нас есть 2 гифки, каждая по 40 кадров, но во второй посление 10 кадров отличаются от первой. Это будет считаться баяном. т.е. нужно чтоб было совпадение по половине кадров всей гифки.
Надеюсь понятно объяснил
Понятно, конечно)
По-моему было бы неплохо, если бы он все возможные варианты показывал, а постящий или проверяющий сам определит, является ли бояном гифки при таких отличиях, хотя возможно это колоссально увеличит нагрузку на сервера и время поиска.
Можно сделать и так. Правда тогда будут тонны вони, о том, что баянометр находит не то, что нужно
хэй
а может сделать возможность выбора между поиском по одному кадру и по остальным?
ну типа если одного не хватило, тогда предлагать искать по всем
Избыточная гроозткость опций. Нужно проще. Забил ссылку, или файл залил, и получил что тебе нужно.
В противном случаи нужно будет постоянно оставлять описание режимов поиска
Имеется в виду, наверное, сделать кнопки по типу без секретных разделов/включая их, расширенный поиск/обычный поиск.
Можно сделать по двум кадрам, первому и последнему? - мне кажется, так должно быть не сложно и относительно трудоемкости и по ресурсам сервера, я, конечно, могу ошибаться.
По всем кадрам дейсвтительно тяжко, но по первому кадру - как-то мало.
Нихуя.
Кстати, о заливке файлов и ссылок.
Очень бы хотелось убрать нахуй автозагрузку. Она иногда нихуя не работала по непонятным причинам, при этом поле со ссылкой редактировать конечно же уже не позволяла

ИМХО:
рядом с полем для выбора файла или ссылки делаем две кнопки "быстрый поиск" и "детальный поиск"
и загружаем файл на проверку только после клика по нужной кнопке. и проверяем его соответственно разными алгоритмами в зависимости от выбранной кнопки
ня?
бери выборку
Requin Requin 17.06.201722:11 ответить ссылка 0.0
чет я ступил....
Requin Requin 17.06.201722:14 ответить ссылка 0.0
Я делал, вот график
10
Graph 1
8
G
4
2
0 ----------------------------------------------------------------------------------------
1	3	5	7	9	10
temp111 temp111 18.06.201701:14 ответить ссылка -3.3
Если сервер выдержит, то да. Если нет, то нет. А еще можно дать возможность всекадрового поиска только вдонатившим на сервер(баянометра) боярам
muted muted 17.06.201721:49 ответить ссылка -0.1
Так теперь на 2 бронепоезда собираем?
Но тот бронепоезд постов, а этот будет бронепоезд-кондуктор, чтобы безбилетники баяны не катались
muted muted 17.06.201722:00 ответить ссылка 0.4
Сервер выдержит. Я пока договорился с знакомыми поделить один дедик, ну и соответственно оплату тоже пополам. Но все таки это не дело. Рано или поздно придется переехать на свои мощностя. Сервера уж больно дорого стоят, чтоб полностью самолично их оплачивать, потому до этого момента хотелось бы собрать свой тазик. Тем более есть где его разместить. Правда даже не представляю, что можно предложить в качестве платных услуг
"ваши посты перестанут быть баянами! другие версии этой картинки удалятся из базы и никто ничего не докажет"
Тут были новости про поиск порнозвёзд на основе нейронных сетей, что если на подобной основе сделать баянометр.
Нейросеть намного затратнее
muted muted 17.06.201722:01 ответить ссылка 1.2
Ну так то да. Таких мощностей у меня нету
А если высчитывать хэши на стороне клиента, а не грузить 100мб срущего кота на сервер?
dstwo dstwo 18.06.201700:39 ответить ссылка 0.1
Тогда у многих будут адские лаги, ибо больше 2-3мб в бразуере - жопа
собираем на 3й бронепоезд
Нет смысла. Та сеть должна выцеплять какие-то семантические признаки (в случае лица были бы описывающие лицо фичи).
Читай - сети лучше подошли бы для задачи поиска похожего контента, а не проверки того, было ли залито такое же изображение.
К тому же - здесь по хорошему нужно брать за основу какой-то классификатор общего назначения, а таких пока вроде нет. Но это будет меньшей проблемой в сравнении с тем, что здесь не нужно никакого машинного обучения :-)

И это не считая того, что pHash - куда менее ресурсозатратная штука, чем перемножение многомегабайтных матриц :-)
Мне стало интерестно, какие характеристи сервера?
muted muted 17.06.201722:09 ответить ссылка 0.1
2 x Xeon X5675 / 24Gb / 4xHDD server NL / MegaRAID 9260 / RAID6 / 4x240Gb SSD / 1 IPv4 / 40Tb (1Gbps port)
мне кажется, нет смысла в ежекадровой сверке, если учесть, что и по одному кадру вместо идентичной гифки или картинки находится какая-то совершенно непохожая дичь
потому и находит не то что нужно, что текущая версия ищет не так как прошлая
Алгоритмы поиска моего варианта и предыдущего похожи. Разница в том, что в моем варианте достукается большее отклонение в картинках
Брать кадры через один
dstwo dstwo 18.06.201700:40 ответить ссылка 0.2
хуйню сморозил
Согласен, но не согласен. Можно еще и пиксели брать через один :) Чисто ради скорости хэширования
dstwo dstwo 18.06.201700:48 ответить ссылка 0.0
Если у тебя в трусах килограм песка, от того что его станет на пол кило меньше ситуация как то измениться?
Я быстрее избавлюсь от полкило песка, чем от килограмма.
dstwo dstwo 18.06.201701:08 ответить ссылка 0.0
А твоя жопа - нет
давай тогда уж просто монетку бросать
bayan = Math.floor(Math.random() * 2);
>> пиксели брать через один
читай за pHash - он и так картинку уменьшает
Если есть возможность, то лучше проводить поиск по всем кадрам. А по первому кадру можно и самому искать: просто берётся URL гифки, меняется расширение .gif на .jpg и вписывается в нужное место /static.
Например:
http://img0.reactor.cc/pics/post/%D0%B3%D0%B8%D1%84%D0%BA%D0%B8-%D1%81%D0%BE%D0%B1%D0%B0%D0%BA%D0%B0-%D0%B5%D0%B4%D0%B0-%D1%80%D0%B5%D1%84%D0%BB%D0%B5%D0%BA%D1%81-3904178.gif -> http://img0.reactor.cc/pics/post/static/%D0%B3%D0%B8%D1%84%D0%BA%D0%B8-%D1%81%D0%BE%D0%B1%D0%B0%D0%BA%D0%B0-%D0%B5%D0%B4%D0%B0-%D1%80%D0%B5%D1%84%D0%BB%D0%B5%D0%BA%D1%81-3904178.jpg
22->23 22->23 17.06.201722:12 ответить ссылка 0.0
Заебись когда выкладывають 200-метровую гифку в 60 fps. Как пользователь - поддерживаю, надо всё хешировать, но как приближённый к этому делу... один хер ты переверни гифку на 90 градусов - и всё, новый
*контент (чёт закрылся пост)
на 90 градусов - это на бочок её положить
ты вероятно имел в виду не 90 и даже не 180, а зеркальное отражение
В принципе, лучше покадрово, иногда бывают гифки одни и те же, но обрезаны немного по разному. Но с другой стороны это, опять же, нагрузка и всё такое. Но я, пожалуй, за покадровую проверку, оно всё-таки баяны будет искать лучше.
я понимаю что говорю очевидные вещи, но все же: ты же в курсе что node.js ограничен 2гб на процесс и таки нужно собирать кластер?
вот могу свою либу тебе прорекламировать (как раз под socket писалась): https://www.npmjs.com/package/express-sticky-cluster
и нод бери 4.5.х+ - они сильно производительность увеличили.
nodejs v4.7.3
Написал под websocket на библиотеке ws
Один поток - чисто под держание websocket
Еще поток - парсер. С дочерними потоками на каждый пост, но не более 20
Для всех клиентов отдельный поток открывается, при получении сообщения
Мое решение достаточно грамотно?
та я же без подъеба, просто недавно столкнулся с небольшой группой разработчиков которые crm на ноде написали - и всё в одном потоке..
я даже сразу разочаровался в человечестве, но ты восстановил мою веру!))
Я без притензий спросил. Может ты чтото получше знаешь
Забавное совпадение. Я как раз сейчас в канторе переписываю свою CRM с трекером.
Поток это процесс nodejs?
Микросервисы это достаточно грамотно
У меня назрел вопрос, баянометр и его сервер - отдельная машина и софт получается?
Мне просто вдруг подумалось что весь joy написан на node, и это было бы классно
джой написан на чем попало. по крайней мере раньше там было миру по нитке
когда-то давно попадался ответ на этот вопрос в старых комментах
joy на php написан, с использованием фреймворка symfony
*был написан на symfony
кока вроде говорил, что минимум на трех языках вставки кода имеются
Значит скорее всего есть python, и еще какой то.
В любом случаи основа в нем осталась таже. PHP и symfony
Спасибо
Баянометр с joyreacotr никак на прямую не связан. Свой сервер и софт. Да, nodejs предлагает достаточно вкусные возможности
Спасибо
Если такое разбиение по процессам, зачем использовать Node? Это же получается охренительно сложно, он не предназначен для мультрединга вообще.
Monyk Monyk 18.06.201701:22 ответить ссылка 0.0
У меня на node получается быстро писать. + он сам по себе асинхронный
Хоть и не понимаю недовольство реализацией через node. C/C++/C# - долго. Python - муторно
То, что ты описал выше - это не асинхронность, это мультитрединг. Нод не может в мультитрединг. Вернее, может, но очень плохо. Обработка картинок и прочие вещи - это просто идеальный антикейс нода, потому что там как раз выгоден мультитрединг. Очень. Идеально бы подошел Elixir, Go или Rust. Но Elixir сам по себе язык сложный с высоким порогом вхождения, Rust чуть попороще, Go очень простой и там зеленая мультитрединговая модель, просто идеально подходит.
Monyk Monyk 18.06.201701:31 ответить ссылка 0.2
Итого. Выучить 3 полумертвых языка ради одного проекта...
Они очень даже живые. И поверь, учить новый язык и на ходу писать на нем проект - это все равно лучше, чем использовать совсем неподходящий инструмент для него. Тебе либо придется кластеризовывать вручную на процессы операционки, либо он у тебя под минимальной нагрузкой просто загнется.
Monyk Monyk 18.06.201709:37 ответить ссылка 0.1
Нода может в мультитрейдинг. Для этого нужны C++ расширения. Я такой трюк и в lua проворачивал, в этом плане js и lua по парадигме идентичные.
Более того, обработка картинок и прочие вещи - как раз таки идеальный кейс для C\C++, с его практически прямой трансляцией в асм и затем машинный код (+ оптимизации под конкретную архитектуру cpu), и именно C\C++ отлично интегрируется с V8.
С/C++/C# геморны в быстрой модификации
Это как прикрутить к вилке изолентой бластер потому что оооооочень сильно хочется использовать вилку, но все-таки нужен бластер. Каждому кейсу свой инструмент, нод просто таки не подходит для таких вещей. Я сам пишу на ноде по работе, но только когда он подходит для задачи. Для мультитредингов и нагружающих процессор задач есть другие инструменты.
Monyk Monyk 19.06.201703:45 ответить ссылка 0.0
Не спорю что C/C++ для подобных задач подошел бы лучше, как и многие другие языки программирования.. Но, это не коммерческий, за создание которого, за все время я получил ~5$ с донатов. На C/C++ я писать тупо не люблю. Потому вопрос. Почему я должен заниматься тем, чем не хочу не получая за это деньги?
Вопрос. Ты тоже любишь и ненавидишь JS?
о да! а ранее я 1с занимался (лет 5 назад) - там ненависти больше было
ну а вообще я больше по реляционным БД выступаю)
через 2 мб?
shumnyj shumnyj 17.06.201722:52 ответить ссылка 0.1
Сделать проверку по N первым кадрам. Скажем, только первые 2 секунды, 60 кадров.
antonc27 antonc27 17.06.201722:53 ответить ссылка 1.2
нафига это вообще надо? люди помнят, где баян. запилите кнопку лучше, натыкали N человек - пост улетает. за абуз фичи - банить. всё
villy villy 17.06.201723:17 ответить ссылка -2.2
Ебать ты гений. Только ты забыл что проще сходу забанить половину реактора
а с этим какие проблемы?
villy villy 17.06.201723:40 ответить ссылка 0.0
ну и куда он там улетает, если даже сейчас с тегом баян посты выходят на главную?
значит эта фича уже не делает возложенной на нее функции и ее можно выкинуть совсем не потеряв в функциональности, не?
смекалистый негр.bmp
villy villy 18.06.201700:03 ответить ссылка -0.3
там вон дело говорят: может стоит не всю гифку проверять, а достаточно только нескольких секунд?
Раньше так и было реализовано: проверялись первые 30 кадров (вот тут написано: http://old.reactor.cc/post/2933322). Вроде такая система работала. Правда, возможны исключения, например:
http://old.reactor.cc/post/3103470
http://old.reactor.cc/post/3112594
22->23 22->23 18.06.201700:05 ответить ссылка 1.0
Ну вот переписываю. Плюшка тяжелая и ресурсоемкая, потому и спрашиваю, нужно оно правда, или нет
без неё оч хуёво работает
я пидор
да всем насрать
сразу видно что ты пидор
Это точно не анон?
Нет, мы выбрались из анона.
на самом деле зачем покадрово? Боянометр же не тупо банит, а говорит, что похожее уже есть, если контент отличается, то автор постит, если нет, то все равно постит, но идет в минуса. Покадровая проверка не нужна, если не будет перманетно не допускать к выкладыванию поста
Flashm6 Flashm6 18.06.201701:17 ответить ссылка 0.0
Если больше 30 кадров, то пропускать некоторые, вроде будет серверам проще жить.
MaXM00D MaXM00D 18.06.201705:41 ответить ссылка 1.1
С одной стороны хорошо бы, с другой стороны: на этих громандных гифках на 100+ мб это трындец будет.
Ну типа я так и знал что так и будет - нужно было выложить тот который работал и потом сидеть пилить новый. Сколько уже прошел? месяц?
bitepix bitepix 24.06.201704:55 ответить ссылка 0.0
ну и че там алло?
bitepix bitepix 09.07.201702:24 ответить ссылка 0.0
Хуй через плече, алло
Завал по работе. На выходных продолжаю пилить
Только зарегистрированные и активированные пользователи могут добавлять комментарии.
Похожие темы

Похожие посты
"Terminator 2" wins Best Makeup Oscar (Stan Winston & Jeff Dawn) - 1992 (1991 year)