Есть 2 метода поиска по гифкам - по первому кадру с гифки, и по всем
На сколько важен полнокадровый поиск? И стоит ли его вообще реализовывать на новом языке
На сколько важен полнокадровый поиск? И стоит ли его вообще реализовывать на новом языке
Нужен ли поиск по каждому кадру гифок?
| Обязательно | |
|
|
1239 (43.5%) |
| Достаточно будет по первому кадру | |
|
|
528 (18.5%) |
| Насрать | |
|
|
724 (25.4%) |
| Нахер гифки | |
|
|
359 (12.6%) |
Еще на тему
Можно pHash-м, а можно и извлеченные resnet-м фичи приюзать (правда, это больше подойдёт для других целей, а не для баянометра)
нынешний только первый кадр проверяет, а прошлый по всем смотрел?
я за улучшенный поиск, но
как сильно скажется на времени поиска и нагрузке разница между вариантами? не сильно ли мы ушатаем сервак поиском гифок по всем кадрам?
Средствами filesystemapi и чего-то типа https://github.com/buzzfeed/libgif-js
К примеру у нас есть 2 гифки. Первая 10 кадров из фильма, вторая 30 кадров, 10 из которых точно повторяют первую
Это не будет считаться баяном. Другая ситуация. У нас есть 2 гифки, каждая по 40 кадров, но во второй посление 10 кадров отличаются от первой. Это будет считаться баяном. т.е. нужно чтоб было совпадение по половине кадров всей гифки.
Надеюсь понятно объяснил
а может сделать возможность выбора между поиском по одному кадру и по остальным?
ну типа если одного не хватило, тогда предлагать искать по всем
В противном случаи нужно будет постоянно оставлять описание режимов поиска
По всем кадрам дейсвтительно тяжко, но по первому кадру - как-то мало.
Кстати, о заливке файлов и ссылок.
Очень бы хотелось убрать нахуй автозагрузку. Она иногда нихуя не работала по непонятным причинам, при этом поле со ссылкой редактировать конечно же уже не позволяла
ИМХО:
рядом с полем для выбора файла или ссылки делаем две кнопки "быстрый поиск" и "детальный поиск"
и загружаем файл на проверку только после клика по нужной кнопке. и проверяем его соответственно разными алгоритмами в зависимости от выбранной кнопки
ня?
безбилетники баяны не каталисьЧитай - сети лучше подошли бы для задачи поиска похожего контента, а не проверки того, было ли залито такое же изображение.
К тому же - здесь по хорошему нужно брать за основу какой-то классификатор общего назначения, а таких пока вроде нет. Но это будет меньшей проблемой в сравнении с тем, что здесь не нужно никакого машинного обучения :-)
И это не считая того, что pHash - куда менее ресурсозатратная штука, чем перемножение многомегабайтных матриц :-)
bayan = Math.floor(Math.random() * 2);
читай за pHash - он и так картинку уменьшает
Например:
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 и даже не 180, а зеркальное отражение
вот могу свою либу тебе прорекламировать (как раз под socket писалась): https://www.npmjs.com/package/express-sticky-cluster
и нод бери 4.5.х+ - они сильно производительность увеличили.
Написал под websocket на библиотеке ws
Один поток - чисто под держание websocket
Еще поток - парсер. С дочерними потоками на каждый пост, но не более 20
Для всех клиентов отдельный поток открывается, при получении сообщения
я даже сразу разочаровался в человечестве, но ты восстановил мою веру!))
Забавное совпадение. Я как раз сейчас в канторе переписываю свою CRM с трекером.
Микросервисы это достаточно грамотно
У меня назрел вопрос, баянометр и его сервер - отдельная машина и софт получается?
Мне просто вдруг подумалось что весь joy написан на node, и это было бы классно
когда-то давно попадался ответ на этот вопрос в старых комментах
кока вроде говорил, что минимум на трех языках вставки кода имеются
В любом случаи основа в нем осталась таже. PHP и symfony
Хоть и не понимаю недовольство реализацией через node. C/C++/C# - долго. Python - муторно
Более того, обработка картинок и прочие вещи - как раз таки идеальный кейс для C\C++, с его практически прямой трансляцией в асм и затем машинный код (+ оптимизации под конкретную архитектуру cpu), и именно C\C++ отлично интегрируется с V8.
ну а вообще я больше по реляционным БД выступаю)
смекалистый негр.bmp
http://old.reactor.cc/post/3103470
http://old.reactor.cc/post/3112594
Завал по работе. На выходных продолжаю пилить