Есть 2 метода поиска по гифкам - по первому кадру с гифки, и по всем
На сколько важен полнокадровый поиск? И стоит ли его вообще реализовывать на новом языке
Нужен ли поиск по каждому кадру гифок?
Обязательно
1239(43,47%)
Достаточно будет по первому кадру
528(18,53%)
Насрать
724(25,4%)
Нахер гифки
359(12,6%)
так вот в чем разница
нынешний только первый кадр проверяет, а прошлый по всем смотрел?
я за улучшенный поиск, но
как сильно скажется на времени поиска и нагрузке разница между вариантами? не сильно ли мы ушатаем сервак поиском гифок по всем кадрам?
нынешний только первый кадр проверяет, а прошлый по всем смотрел?
я за улучшенный поиск, но
как сильно скажется на времени поиска и нагрузке разница между вариантами? не сильно ли мы ушатаем сервак поиском гифок по всем кадрам?
энд вот эбаут гифки по 100мб?
ЕМНИП, кстати, этот наш JS же позволяет парсить на клиенте.
Средствами filesystemapi и чего-то типа https://github.com/buzzfeed/libgif-js
Средствами filesystemapi и чего-то типа https://github.com/buzzfeed/libgif-js
то есть если два чувака взяли одно видео и обрезали из него ключевой момент, но с разницей в 1 секунду, то это типа уже не баян по твоему?
Баян конечно, но если б так было проще реализовать, то был бы выход. Если б эти 2 чувака обрезали что-то то скорее всего и количество кадров было различным. Кстати сказать, в покадровом сравнении тоже баян ведь пройдет если скажем к оригинальной гифке вконце прилепили какую-то фиговину.
Ты не понял в чем суть. Проверяется не соответсвие каждому кадру, а примерное совпадение каждого кадра.
К примеру у нас есть 2 гифки. Первая 10 кадров из фильма, вторая 30 кадров, 10 из которых точно повторяют первую
Это не будет считаться баяном. Другая ситуация. У нас есть 2 гифки, каждая по 40 кадров, но во второй посление 10 кадров отличаются от первой. Это будет считаться баяном. т.е. нужно чтоб было совпадение по половине кадров всей гифки.
Надеюсь понятно объяснил
К примеру у нас есть 2 гифки. Первая 10 кадров из фильма, вторая 30 кадров, 10 из которых точно повторяют первую
Это не будет считаться баяном. Другая ситуация. У нас есть 2 гифки, каждая по 40 кадров, но во второй посление 10 кадров отличаются от первой. Это будет считаться баяном. т.е. нужно чтоб было совпадение по половине кадров всей гифки.
Надеюсь понятно объяснил
По-моему было бы неплохо, если бы он все возможные варианты показывал, а постящий или проверяющий сам определит, является ли бояном гифки при таких отличиях, хотя возможно это колоссально увеличит нагрузку на сервера и время поиска.
Так теперь на 2 бронепоезда собираем?
Сервер выдержит. Я пока договорился с знакомыми поделить один дедик, ну и соответственно оплату тоже пополам. Но все таки это не дело. Рано или поздно придется переехать на свои мощностя. Сервера уж больно дорого стоят, чтоб полностью самолично их оплачивать, потому до этого момента хотелось бы собрать свой тазик. Тем более есть где его разместить. Правда даже не представляю, что можно предложить в качестве платных услуг
"ваши посты перестанут быть баянами! другие версии этой картинки удалятся из базы и никто ничего не докажет"
Тут были новости про поиск порнозвёзд на основе нейронных сетей, что если на подобной основе сделать баянометр.
Нет смысла. Та сеть должна выцеплять какие-то семантические признаки (в случае лица были бы описывающие лицо фичи).
Читай - сети лучше подошли бы для задачи поиска похожего контента, а не проверки того, было ли залито такое же изображение.
К тому же - здесь по хорошему нужно брать за основу какой-то классификатор общего назначения, а таких пока вроде нет. Но это будет меньшей проблемой в сравнении с тем, что здесь не нужно никакого машинного обучения :-)
И это не считая того, что pHash - куда менее ресурсозатратная штука, чем перемножение многомегабайтных матриц :-)
Читай - сети лучше подошли бы для задачи поиска похожего контента, а не проверки того, было ли залито такое же изображение.
К тому же - здесь по хорошему нужно брать за основу какой-то классификатор общего назначения, а таких пока вроде нет. Но это будет меньшей проблемой в сравнении с тем, что здесь не нужно никакого машинного обучения :-)
И это не считая того, что pHash - куда менее ресурсозатратная штука, чем перемножение многомегабайтных матриц :-)
мне кажется, нет смысла в ежекадровой сверке, если учесть, что и по одному кадру вместо идентичной гифки или картинки находится какая-то совершенно непохожая дичь
потому и находит не то что нужно, что текущая версия ищет не так как прошлая
хуйню сморозил
давай тогда уж просто монетку бросать
bayan = Math.floor(Math.random() * 2);
bayan = Math.floor(Math.random() * 2);
Если есть возможность, то лучше проводить поиск по всем кадрам. А по первому кадру можно и самому искать: просто берётся 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
Например:
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
на 90 градусов - это на бочок её положить
ты вероятно имел в виду не 90 и даже не 180, а зеркальное отражение
ты вероятно имел в виду не 90 и даже не 180, а зеркальное отражение
я понимаю что говорю очевидные вещи, но все же: ты же в курсе что node.js ограничен 2гб на процесс и таки нужно собирать кластер?
вот могу свою либу тебе прорекламировать (как раз под socket писалась): https://www.npmjs.com/package/express-sticky-cluster
и нод бери 4.5.х+ - они сильно производительность увеличили.
вот могу свою либу тебе прорекламировать (как раз под socket писалась): https://www.npmjs.com/package/express-sticky-cluster
и нод бери 4.5.х+ - они сильно производительность увеличили.
Поток это процесс nodejs?
Микросервисы это достаточно грамотно
У меня назрел вопрос, баянометр и его сервер - отдельная машина и софт получается?
Мне просто вдруг подумалось что весь joy написан на node, и это было бы классно
Микросервисы это достаточно грамотно
У меня назрел вопрос, баянометр и его сервер - отдельная машина и софт получается?
Мне просто вдруг подумалось что весь joy написан на node, и это было бы классно
джой написан на чем попало. по крайней мере раньше там было миру по нитке
когда-то давно попадался ответ на этот вопрос в старых комментах
когда-то давно попадался ответ на этот вопрос в старых комментах
*был написан на symfony
кока вроде говорил, что минимум на трех языках вставки кода имеются
кока вроде говорил, что минимум на трех языках вставки кода имеются
Спасибо
Спасибо
То, что ты описал выше - это не асинхронность, это мультитрединг. Нод не может в мультитрединг. Вернее, может, но очень плохо. Обработка картинок и прочие вещи - это просто идеальный антикейс нода, потому что там как раз выгоден мультитрединг. Очень. Идеально бы подошел Elixir, Go или Rust. Но Elixir сам по себе язык сложный с высоким порогом вхождения, Rust чуть попороще, Go очень простой и там зеленая мультитрединговая модель, просто идеально подходит.
Они очень даже живые. И поверь, учить новый язык и на ходу писать на нем проект - это все равно лучше, чем использовать совсем неподходящий инструмент для него. Тебе либо придется кластеризовывать вручную на процессы операционки, либо он у тебя под минимальной нагрузкой просто загнется.
Нода может в мультитрейдинг. Для этого нужны C++ расширения. Я такой трюк и в lua проворачивал, в этом плане js и lua по парадигме идентичные.
Более того, обработка картинок и прочие вещи - как раз таки идеальный кейс для C\C++, с его практически прямой трансляцией в асм и затем машинный код (+ оптимизации под конкретную архитектуру cpu), и именно C\C++ отлично интегрируется с V8.
Более того, обработка картинок и прочие вещи - как раз таки идеальный кейс для C\C++, с его практически прямой трансляцией в асм и затем машинный код (+ оптимизации под конкретную архитектуру cpu), и именно C\C++ отлично интегрируется с V8.
Это как прикрутить к вилке изолентой бластер потому что оооооочень сильно хочется использовать вилку, но все-таки нужен бластер. Каждому кейсу свой инструмент, нод просто таки не подходит для таких вещей. Я сам пишу на ноде по работе, но только когда он подходит для задачи. Для мультитредингов и нагружающих процессор задач есть другие инструменты.
ну и куда он там улетает, если даже сейчас с тегом баян посты выходят на главную?
там вон дело говорят: может стоит не всю гифку проверять, а достаточно только нескольких секунд?
Раньше так и было реализовано: проверялись первые 30 кадров (вот тут написано: http://old.reactor.cc/post/2933322). Вроде такая система работала. Правда, возможны исключения, например:
http://old.reactor.cc/post/3103470
http://old.reactor.cc/post/3112594
http://old.reactor.cc/post/3103470
http://old.reactor.cc/post/3112594
без неё оч хуёво работает
да всем насрать
сразу видно что ты пидор
Это точно не анон?
на самом деле зачем покадрово? Боянометр же не тупо банит, а говорит, что похожее уже есть, если контент отличается, то автор постит, если нет, то все равно постит, но идет в минуса. Покадровая проверка не нужна, если не будет перманетно не допускать к выкладыванию поста
С одной стороны хорошо бы, с другой стороны: на этих громандных гифках на 100+ мб это трындец будет.
Чтобы написать коммент, необходимо залогиниться
