Emil
Общение сервисов платформа-агностично
Гугл наверное по http3 уже гоняет на го
🅞leksiy
NN
Общение сервисов платформа-агностично
Гугл наверное по http3 уже гоняет на го
gRPC переехал на http3?
Alexander
кто-нибудь может натолкнуть на алгоритм для некого обобщения изображений, вроде того когда на глаз они идентичны, но по факту нет? не знаю даже какой запрос сделать. пример:
Alexander
Alexander
Alexander
Сравнил сейчас, тут разница видна. Но часто не столь заметна
Alexander
Надо какие-то хэши собирать, чтобы достаточно похожие не выдавать по итогу
Emil
кто-нибудь может натолкнуть на алгоритм для некого обобщения изображений, вроде того когда на глаз они идентичны, но по факту нет? не знаю даже какой запрос сделать. пример:
Хз оно или нет, но тут алгоритмы определения боянов на пикабу
(Хотя наверное недостаточно точные)
((А я вчитался, вообще не то, просто ассоциация была))
Alexander
таки да, в основном разница в качестве изображения. пока не сравниваешь лицо в лицо - разницы как бы и нет
Alexander
хочется попроще чего
Alexander
у меня нет каких либо искажений и прям супер разницы, когда один жпег 99%, а другой 50%
Alexander
грубо говоря из левой и правой картинки путем аппроксимации получить одну, но сильно не растеряв детали
Vitaly
Vitaly
на ум пришла такая штука. использовать наложение слоев, а затем высчитать какое-нибудь соотношение. скажем, после приведения к чб и количеству белого к площади картинки.
наложение слоев как в фотошопе, одним из способов.
чтобы размытые пиксели перекрыли четкие. операция вроде вычитания. и если будут расхождения, то может они будут заметны.
можно поиграться в фотошопе подобрать операцию
Vitaly
кто-нибудь может натолкнуть на алгоритм для некого обобщения изображений, вроде того когда на глаз они идентичны, но по факту нет? не знаю даже какой запрос сделать. пример:
а к проекту какого рода такая фича полезна?
Alexander
я так понял речь о сравнении двух изображений между собой, очень дорого. хотелось бы получить какой-то слепок, который можно быстро сравнить на идентичность или близкость как бы
Alexander
а к проекту какого рода такая фича полезна?
ну у меня есть картинки найденные на разных сайтах, надо дать их людям для некоего выбора, но видимо есть варианты когда где-то одно изображение попадается на разных страницах, но оно чуть зашакалено в одном из случаев. хочется сократить объем выдаваемых картинок
Alexander
в какой-то дата саенс ударятся не хочется, ибо на первый взгляд все очевидно: применяем преобразования, вычисляем какие-то суммы и если расхождение небольшое - то, что нам надо.
Alexander
в какой-то степени даже нахождение средних r g b компонент дает то, что мне надо
Alexander
выборка по итогу небольшая будет сравниваться (до 100), но надо на лету. самое простое пока хранить даунскейл до супер маленьких размеров вроде 10 на 10
Alexander
выборка по итогу небольшая будет сравниваться (до 100), но надо на лету. самое простое пока хранить даунскейл до супер маленьких размеров вроде 10 на 10
хотя тут тоже разница небольшая выходит
🅞leksiy
хотя тут тоже разница небольшая выходит
Нужно отклонения попиксельно высчитывать на небольшом разрешении. Можно в теории цветом пренебречь. Но это не поможет, если картинка обрезана
🅞leksiy
https://github.com/vitali-fedulov/images
Alexander
Спасибо, осталось сериализовать эти хэши
Alexander
Неплохо, гзипанный максимально хэш от 900 на 900 меньше килобайта выходит
Alexander
так у меня не будет никаких сдвигов скорее всего
Alexander
ну и опять же вроде либа ок работает, мне подходит
Alexander
не хочу ML, я же писал
Alexey
Только начал изучать го. Боб Мартин писал, что нужно использовать либо структуры + процедуры, либо объекты, в зависимости что нужно расширять. В ООП предпочтение отдается объектам и полиморфизму. Но в го используются структуры, но вместо процедур уже методы. Не могу понять парадигму го, это всё таки ООП и следует работать как с ООП, скрывать данные и работать с ними через методы, или же в го открытые структуры с процедурами, как описывал мартин?
Alexander
так они выбирать будут уже из готового
Alexander
у них не будет идентичных на человеческий взгляд изображений. тупые или нет - уже не моя проблема
Alexander
Только начал изучать го. Боб Мартин писал, что нужно использовать либо структуры + процедуры, либо объекты, в зависимости что нужно расширять. В ООП предпочтение отдается объектам и полиморфизму. Но в го используются структуры, но вместо процедур уже методы. Не могу понять парадигму го, это всё таки ООП и следует работать как с ООП, скрывать данные и работать с ними через методы, или же в го открытые структуры с процедурами, как описывал мартин?
инкапсуляция рулит, тем более в языке есть приватные поля и методы. но опять же инкапсуляция это не getField() и setField(). я считаю, что все как в других языках следует делать. конечно, там где разумен прямой доступ - не надо скрывать его
byd
Боб рулит
Alexey
Понял, спасибо. Имею ввиду если я пришёл с ООП языка, типа джавы. Не пойму как работать с парадигмой го. В го ООП или что, просто структуры несколько противоречат объектам
Alexander
а в чем их различия?)
Alexander
просто из-за отсутствия наследования код немного другой получается, а так по сути это то же ООП
Alexander
только особенное
Alexey
а в чем их различия?)
Из книги боба: объекты скрывают свои данные за абстракциями и предоставляют функции, работающими с этими данными.
Структуры данных раскрывают свои данные и не имеют осмысленных функций.
Знаю в го биндятся методы к структурам и есть интерфейсы, получается я могу работать со структурами как с объектами?
Alexander
ну а приватные поля и методы для чего придумали?
Alexander
интерфейсы для чего придумали?
Herman
инкапсуляция рулит, тем более в языке есть приватные поля и методы. но опять же инкапсуляция это не getField() и setField(). я считаю, что все как в других языках следует делать. конечно, там где разумен прямой доступ - не надо скрывать его
Хм, а есть какая-то формализация, когда разумно, а когда уже не очень?
Alexey
Я понимаю, сори возможно мои вопросы кажутся глупыми, просто пытаюсь понять как писать на го после классов
Alexey
Это не инкапсуляция, и даже не про сокрытие, ну отчасти
Alexey
Инкапсуляция это объединение данных и функций, работающих с ними в рамках конструкции языка. То есть в го это те же структуры и методы. Мартин же говорит про сокрытие за абстракцией. Когда скрывает устройство твоих данных, и предоставляешь только методы работы с ними
Alexander
Я понимаю, сори возможно мои вопросы кажутся глупыми, просто пытаюсь понять как писать на го после классов
Ну смотри, вместо принятия потомков базового класса интерфейсы, вместо переопределения какого-то поведения в потомке добавляем поле реализующее интерфейс и в рантайме выбираем какого реализатора туда поставить
Alexander
Чего ещё тебе не хватает?
Alexander
Получается даже интереснее в плане разделения
Alexey
Alexey
А при чём тут пхп?
Alexander
Конструкторов нет, тут варианта три:
1. Делаем интерфейс для нашей структуры. Делаем тип структуры приватным, интерфейс публичным. Делаем метод возвращающий интерфейс, который по сути конструктор. Такого почти не видел.
2. Делаем поведение неициализированной ненулевыми значениями структуры рабочим. Такое часто делают в стандартной либе.
3. Забиваем на всё. Пусть пользуются неработающей структурой - сами дураки. Такое делают очень часто(
Alexander
Деструкторов нет
Alexey
Скорее тогда уж джава или шарпы, там вся сила ооп
Alexander
С маленькой и большой буквы
🅞leksiy
Я смотрю тут все мастера ООП собрались) Какие кто реально объекты писал, ну чтобы прям с наследованием, полиморфизмом и тп? Просто интересно
🅞leksiy
Кроме User и подобного
Alexander
Хм, а есть какая-то формализация, когда разумно, а когда уже не очень?
Ну это все вкусовщина, имхо. Опять же надо смотреть, будет ли из-за инкапсуляции хуже производительность или нет. Для примера, вот есть у нас Point {X, Y}. Зачем нам скрывать координаты за геттерами, сеттерами? Ну ок, мы можем сделать методы MoveX, MoveY или типа точка у нас константа и вот не надо ее менять, только получаем из нее координаты. Идеологично? Да. Но надо ли?
Alexander
не понял причем тут пыха. там как раз ООП классическое, со всеми заморочками и даже больше, чем нужно
Alexander
Я смотрю тут все мастера ООП собрались) Какие кто реально объекты писал, ну чтобы прям с наследованием, полиморфизмом и тп? Просто интересно
хыхых, когда базу для чего-то пишешь, то вполне
Alexey
Ну это все вкусовщина, имхо. Опять же надо смотреть, будет ли из-за инкапсуляции хуже производительность или нет. Для примера, вот есть у нас Point {X, Y}. Зачем нам скрывать координаты за геттерами, сеттерами? Ну ок, мы можем сделать методы MoveX, MoveY или типа точка у нас константа и вот не надо ее менять, только получаем из нее координаты. Идеологично? Да. Но надо ли?
Ну как в той же книге Мартина пример был: чтобы скрыть реализацию. Пилишь Фотошоп, сначала была декартова, потом полярная система координат. Если координаты открыть, то придется вообще всё переписывать, а если скрыть и предоставлять только методы работы с данными, типа добавить точку на координату, то весь код будет работать как и раньше
Alexander
Ну как в той же книге Мартина пример был: чтобы скрыть реализацию. Пилишь Фотошоп, сначала была декартова, потом полярная система координат. Если координаты открыть, то придется вообще всё переписывать, а если скрыть и предоставлять только методы работы с данными, типа добавить точку на координату, то весь код будет работать как и раньше
а если скрыть, то будет все тормозить))
Alexander
и как раз для фотошопов не пойдет
Alexey
Почему? Как это влияет на производительность?
🅞leksiy
Никак
Alexey
Я просто го пока не очень знаю, но в той же джаве разницы никакой
Alexander
я могу представить, что если у тебя координаты в другой системе координат, то быстрее будет использовать методы работающий в этой системе координат, чем конвертировать
Alexander
либо изначально сконвертировать в нужную и делать все операции в ней
Alexey
В го приватные свойства медленней работают чем открытые?
Alexander
нет
🅞leksiy
Допустим метод преобразует каждый раз координаты
🅞leksiy
В таком случае будет замедление в сравнении с получением данных напрямую из свойства уже в нужном формате.
Alexey
В таком случае будет замедление в сравнении с получением данных напрямую из свойства уже в нужном формате.
Понял, спасибо за объяснение
Emil
Os.getenv есть и сторонние библиотеки для .env
(Если речь об этом, не питонист)
Alexander
вообще, разработчику фотошопа нужно думать о том, чтобы в кэши все укладывалось и о том, чтобы SIMD инструкции максимально отрабатывали, а не о том как идиоматично все описать. мне представляется, что все-таки публичные поля тут куда проще даже в том, чтобы осмыслить алгоритмы
Alexander
есть подозрения, что это все не рука об руку идет. но могу ошибаться
Emil
Go by example
The tour of go
У фрикодкампа на Ютьюбе есть 7 часовой курс для начинающих
Alexander
это же немного другое, алгоритм интерполяции для картинки с массивом пикселей работает обычным совершенно