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

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

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

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

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

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

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

временная сложность 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 байт не совпал, чтобы хэши разные получились

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

Всё так

так вот, если разница в 1 пикселе — попиксельное сравнение ок, решает проблему же

У них там какой-то CDN стоит, где пачка серваков с картинками и я так понимаю, они их чередуют. То есть картинки одни и те же, но, видимо, на каком-то из этих серваков они чуть иначе пожаты и я постоянно ловлю отчёты что картинки поменялись

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

Тут opencv поможет

Там вроде были такие алгоритмы сравнения

Ну а я бы сеточку обучил на это :)

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

https://github.com/mapbox/pixelmatch

https://github.com/mapbox/pixelmatch

Ага, и последние коммиты в некоторые файлы с сообщением "throw error on image size mismatch") Но если задача сводится к действительно "одинаковым" картинкам, то похоже на хорошее решение. ImageMagick тоже умеет такое, например.

Ну там оно под несколько специфичные цели, но посмотреть можно

Тем более если есть предположение что это из за пережатия

От пережатия спасёт, сам когда-то подобное внедрял, не помню даже на чём) Но вот любой ресайз/кроп/compose картинки - всё, труба. До гугла и всяких tineye - как до луны.

/stat@combot

/stat@combot

/stat@combot

господа, а кто как обновляет схему БД скажем монго дб, при обновлении приложения

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

как вы это делаете от релиза к релизу

?

Так схемы то нет

знал что будет такой вопрос

поэтому я "расширил" вопрос ниже предложением

В общем подход такой

Можно добавлять все поля как необязательные навсегда

Тогда ничего делать не нужно

я ща объясню к чему - я это. Вопрос консистенции. Когда я релижу сайтец у себя сам на сервере, в принципе это всеравно, но когда у тебя условно веб приложение, которое использует Компания А, ты ей отгрузил версию 1.0.0 но потом ты релизишься скажем несколько раз и там меняешь данные в бд, потом ребята хотят обновиться а БД поменялась скажем, получается что нужно добавлять как-то данные в коллекции

вот интересен опыт

кто как разруливает

я видел делают по принципу папочку и там скрипты, но видел я тока для SQL

как делается это для монги

Ну здесь можно сделать тоже самое

я тут нашел https://www.npmjs.com/package/database-updates

не знаю юзал кто?

Если речь о софте, который периодически обновляется, то это может непросто

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

вот серия таких скриптов

на апдейт базы

и тогда можно с версии на версию

просто мало инфы вообще об этом

мало кто говорит вообще об этом

ну нужно чото типа привязки скриптов миграции БД к версиям релизов

вот тоже к этому склоняюсь

я бы делал по-нубски примитивно

На старте приложения проверяется формат БД и если он не тот, который нужен, то сразу на горячую и исправляется

Надёжно как топор

Слишком сложно проверять формат

Но кому-то не подойдёт из-за увеличенного на пару сотен миллисекунд времени запуска

Слишком сложно проверять формат

Ну в SQL не сложно

Тоже сложно

эээ чем?

Ну нужно проверить каждое поле на присутсвие по сути

Нет, надо проверить таблицы и типы столбцов