мне нравится то что можно в ноде из коробки :)

ну и пыха так-то сессии могёт

хреново могёт :)

файловые вообещ лочатся, если 2 коннектами придешь по одной сессии, пока первая не отлочится, чторая ждет

я на этом однажды несколько часов потерял, пока дошло что не так

такой вот вопрос, в ноде получается на каждый коннект как бы отдельный инстанс окружения генерируется что ли?

мне нравится то что можно в ноде из коробки :)

да, на то и нужно знать разные технологии, чтобы грамотно их выбирать под подходящие задачи

может есть чо почитать на эту тему?

как эти множественные стейты и эвентлуп разруливаются

и как они могут друг с другом взаимоейдствовать

исходники v8?

ну как вариант, но хотелось бы в более сжатом виде, так сказать для чайников :)

пасаны посоветуйте какой нить поисковой scrapper, без всяких ключей шоб

Рили?

Рили

пасаны посоветуйте какой нить поисковой scrapper, без всяких ключей шоб

Чем плох express + cheerio?

Чем плох express + cheerio?

не, мне надо чтобы пишешь запрос, а он в ответ выдавал первый результат из гугла например

Ну да

забрал, распарсил, отдал

это ж надо вручную писать :0

в 2к16

гугл не любит когда его парсят и старается бороться с этим

гугл не любит когда его парсят и старается бороться с этим

И правильно делает

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

В смысле, её автоматизация

#вопрос Господа, подскажите, как понимать что изображенгие по ссылке изменилось? При том что ссылка не менялась. До сих пор решал вопрос сравнением хэша от base64, но щас наткнулся на то, что некоторые картинки меняются неразличимо для глаза. Их чем-то пережимают, наверное. Как можно отфильтровывать эти случаи?

может быть смотреть ответ от сервера? 200 и 304

вроде

или это я херню сморозил?

или это я херню сморозил?

+

:(

Я скачал картинку А, перегнал её в base64, схоронил. Я скачал картинку Б, перегнал её в base64, схоронил. У картинок А и Б разный base64, но на глаз они неразличимы. Как понять что по сути это одна картинка?

А то получать такие отчёты чото не айс совсем http://puu.sh/sM1Xz/e0cc8e1065.png

гугл не любит когда его парсят и старается бороться с этим

Против лома нет приёма. horseman, nightmare

Я скачал картинку А, перегнал её в base64, схоронил. Я скачал картинку Б, перегнал её в base64, схоронил. У картинок А и Б разный base64, но на глаз они неразличимы. Как понять что по сути это одна картинка?

попробуй MD5 с них сделать

будет совпадать или нет

Я и делаю

md5(base64)

может там оптимизации какие или вотермарки лепит енджинкс например

таймстемпы например

или метаинформация меняется

побайтно сравнить попробуй бинарно

Ну вот да, чот такое

А чем?

попробуй MD5 с них сделать

base64 разные, хэш от него, соответственно тоже

в целом можно прогнать картинки фильтрами

чтобы несущественные нюансы сгладить

но, опять же, там не факт что получится прям 1 в 1

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

ох, чото запахло СЛОЖНАСТЬЮ

дак да

учитывая что на каждый пиксель по 3 х 256 значения идет, а если пнг, то 4 х 256, там можно в широких пределах картинку менять, на глаз вообще видно не будет, тем не менее бинарно это будут разные картинки

ну вот да

делает меня грустить

ну в таких случаях нужно сознательно понижать детализацию

например можно кратно понизить разрешение, прогнать в грейскейл, или даже в индексированные цвета

хм, хорошая идея, спасибо

Нетривиальная задачка, да)

и посчитать с получившейся картинки некий хэш

продумать формулу так, чтобы незначительные отличия в пару тонов не сильно сказывались на конечный результат

например можно кратно понизить разрешение, прогнать в грейскейл, или даже в индексированные цвета

Индексированные цвета будут промахиваться, grayscale проблемы тоже не решает. Поблочно сравнивать наверное

А есть же постгревый similarity, он позволяет сравнивать блобы.

Не знаю переносили его на 9.6 или нет, но на 9.5 работает

Разбить изображение на n x n небольших блоков, в каждом из них усреднить значение цвета, на выходе будет вектор, который уже вполне можно сравнивать

Разбить изображение на n x n небольших блоков, в каждом из них усреднить значение цвета, на выходе будет вектор, который уже вполне можно сравнивать

если предварительно кратно понизить разрешение, и проиндексировать цвета, то будет примерно то же :) только на порядок меньше телодвижений процом :)

Столько же

Возможно даже побольше

ERROR: S client not available

Хотя в принципе это и есть понижение разрешения, да)

тут суть в том, что небольшие различия усредняются при понижении разрешения

в т.ч. всякие там вотермарки

Зато не получится прервать после первого различия, в любом случае придётся считать весь лист

логично однако

об этом не подумал

по-моему, достаточно свести изображения к одинаковому разрешению, и посчитать попиксельно разницу по каждому цвету (и прозрачности), сложить модули разниц, вывести процент различия по пикселу, посчитать среднее арифметическое для всего массива пикселей. получится вероятность различия. установить допустимый порог

по-моему, достаточно свести изображения к одинаковому разрешению, и посчитать попиксельно разницу по каждому цвету (и прозрачности), сложить модули разниц, вывести процент различия по пикселу, посчитать среднее арифметическое для всего массива пикселей. получится вероятность различия. установить допустимый порог

Звучит как хороший план, если бы не колчиство проверок такого типа, которые надо сделать

Ну в общем надо подумать

Спасибо за пищу для размышлений

временная сложность O(N) где N — количество пикселей

это да

по-моему, достаточно свести изображения к одинаковому разрешению, и посчитать попиксельно разницу по каждому цвету (и прозрачности), сложить модули разниц, вывести процент различия по пикселу, посчитать среднее арифметическое для всего массива пикселей. получится вероятность различия. установить допустимый порог

Попиксельно не получится, артефакты сжатия

Попиксельно не получится, артефакты сжатия

можем проверить. я не знаю ответа

хотя не, впадлу )

все таки я думаю надо усреднять группы 2х2 или 3х3 или NxN или даже NxM

так погрешность на всякие невидимые глазу артефакты будет размываться и пороги надо будет ставить ниже

все таки я думаю надо усреднять группы 2х2 или 3х3 или NxN или даже NxM

Это эмпирически, так не проверить

кстати, про альфа-канал )))

Вредоносная версия картинки баннера имеет в своем составе зашифрованный скрипт, располагающийся в альфа-канале RGB изображения. Этот альфа-канал задает прозрачность каждого пикселя. Поскольку это изменение не сильно сказывается на внешнем виде картинки, она лишь незначительно отличается от ее оригинальной версии. https://m.habrahabr.ru/company/eset/blog/317092/

в общем как план сводить к 16×16 пикселей (условно) и считать различия цветов в пределах некой погрешности

так погрешность на всякие невидимые глазу артефакты будет размываться и пороги надо будет ставить ниже

это просто предварительное усреднение, ошибка никуда не девается

вы ещё не забывайте, что картинки некратных разрешений будут очень нетривиально различаться после интерполяции, если сравнивать попиксельно

кажется, для этой проблемы лучше поискать готовое решение :)

а перед этим точно определиться с требованиями к решению: какие случаи должны распознаваться как одна и та же картинка

дак у чела по одному и тому же урлу я думаю одного и того же разрешения картинки прилетают

он говорит они на глаз не различимы

а хеши разные дают

там достаточно чтобы 1 байт не совпал, чтобы хэши разные получились

а челу надо определиться, это та же картинка или нет

Всё так