Найди друга по любимым артам

+83
в блоге IT Pony!
На многих популярных ресурсах рекомендуются друзья, основываясь на ваших общих интересах. До сих пор я не встречал ничего подобного в брони-фандоме, и я решил это исправить. На данный момент функционал программы очень простой, но эффективный — вы вбиваете свой ник, и он показывает список брони, у которых больше всего похожих артов в избранном на Дерпибуре:
github.com/Sasha-Flyer/brony-finder
Если у вас нет возможности установить Python или вы не можете работать с такими большими даннами, как база Буры — напишите прямо в пост, я сделаю поиск по вашему нику и скажу, с кем вы, возможно, подружитесь. (сайт и дополнительный функционал появятся, если будет интерес к идее)
Вывод программы крайне простой:
['Tyler_Cunn', 0.7647058823529411]
['SPltFYre', 0.7428571428571429]
['Coffee_Pie', 0.7297297297297297]
['Bananaphone', 0.7058823529411765]
['LiquidFireN2X', 0.7027027027027027]
['Nicknak', 0.6944444444444444]
['billybutt72', 0.6857142857142857]
['PrivateSkittles', 0.6857142857142857]
['Rainbow Z', 0.6857142857142857]

Чем ближе значение к единице, тем больше у вас общих интересов.

Теги:

  • В избранное
    1

87 комментариев

В ленту! Если идея понравится, то сделаю ещё поиск по тегам вашего избранного — в теории такой поиск подберет еще более подходящих юзеров, с которыми вы можете подружиться.
ЛОЛ. Саня, а слабо мне найти друга по тегам: некрофилия, гуро, расчленёнка, канибализм? )))
А если найдёт?)
Таких людей, скорее всего, в природе не существует. Я же прикалываюсь.
Вполне найдётся. Может кто-то скрывается?
Если отмести некрофилию, то один такой точно есть. И я его знаю
Не, ну гурятинку много кто любит. Я сам… многих знаю. Тут шутка была именно в комбинации. ;)
Я понимаю про шутку. Это я так

P.S. кстати. Само слово гуро вне поней вроде как применяется к расчленёнке с эротическим подтекстом. Не стоит ли это тогда считать тем же самым, что и некрофилия?
Я понял. )))

Слушай, а вот ХЗ. Я под гуро в принципе насилие понимаю, не обязательно с сексуальным подтекстом как при некрофилии. Например, садист-убийца, но не насильник, творит гурятинку, но некрофилией не занимается.
Задумалась прост над этим, вспомнив как гуглила значение слова.
И меня смутило это

Описывается как вообще конкретно эротическая расчленёнка. То есть, получается, что гуро и гримдарк — это разные вещи, если исходит из этого. Расчленёнка, но разного назначения. Но опять же ниипу. Где-то пишут, что это изначально эрогуро, просто сокращено. А где-то, что есть два направление — гуро и эрогуро. Кому верить — хз
гуро и гримдарк — это разные вещи


Ну, я иной позиции придерживаюсь. Эрогуро для меня более узкий подвид гурятинки. Но я не профессор в этом деле, могу и ошибаться. :D
Ну, как показывают Ысточники, в тч Вики, эрогуро и гуро — изначально одно и тоже. Может быть на слэнге слова в итоге заимели разное значение. И сокращённое гуро стало синонимом гримдарку
Хз, мне второе слово больше нравится
Ну, всё же гримдарк это мрачные жёпы и вовсе не обязательно разрезанные. А гуро это именно разрезанные, но уже не обязательно мрачные.
Да ты прямо Сократ!
А то.
Когда будет реализован поиск по тегам — он будет работать не совсем так, как ты сейчас это представил. Под каждый тег для каждого юзера будет выделено ровно 2 бита, уникальные сочетания:
00 — юзеру совершенно не интересен этот тег
01 — у юзера есть немного артов с этим тегом
10 — юзеру определенно нравится этот тег
11 — юзер фанатеет от этого тега
И затем эти данные будут побитово сравнится со всеми предпочтениями всех пользователей, и будут показаны юзеры, у которых больше всего полных совпадений.
Изначально я хотел выделить «00» под «юзер заблокировал этот тег», но как я понял, эта информация не публичная.
Эм, Александр, я вообще-то пошутил про поиск…
Ты есть на Буре?))
Конечно… нет. На хрена мне на сомнительном сайте регистрироваться? )))
Чтобы добавлять в избранное понравившиеся арты, и затем находить друзей со схожими увлечениями?)
Если что-то нравится человеку, то он это тупо сохраняет. Из интернета понравившееся тебе всегда могут удалить. Тем более с Буры с её дебильным DNP, BLM и прочей хернёй.
находить друзей со схожими увлечениями?)


Друзей — сомневаюсь, разве что заклятых врагов. :D
друзей

содрочильников
ЛОЛ. Тут уже голландским штурвалом попахивает…
А что в этом плохого?
А таки шо в энтом хог'ошего, молодой человек?
Избранное нинужно, друзья тоже нинужно (introvert lives matter)
Ты кто по масти будешь, брат интроверт? Я ИЛИ (Интуитивно Логический Интроверт), но с примесью…
Встроенная аналитика и майнер присутствуют?)
исходный код прямо по ссылке. Ничего там нет такого) И как я писал — если нет возможности такое запустить, и если есть аккаунт на Буре с избранными артами — скажи ник, сам поищу)
Аккаунт — лишнее. Этож не девиант.
Аккаунт нужен, чтобы добавлять арты в избранное.
Идея любопытная, но вряд ли взлетит
Ну а вдруг)
Так и представляю
— Привет!
— Привет… а с чего ты решил мне написать
— У нас одинаковые вкусы в… Ну ты понял
А в избранном копрофилия и уринофилия. :D
stsyn
лучшие совпадения:
['stsyn', 1.0]
['kk0425', 0.05951405951405951]
['Doctor The I', 0.05801273663089942]
['angel767', 0.0523887483256437]
['JohanssenJr', 0.052368879733798133]
['dandy1', 0.051218759642085776]
['Bracken', 0.04800977653631285]
['Weenie', 0.0476250952501905]
['mordrak', 0.04742268041237113]
['FancyMareInBlue', 0.04663857498563494]

хоть совпадение всего 6%, в общем интересы совпадают с твоими. У вас определнённо есть общие вкусы
Doctor The I

Я знаю, что он фавит кучу фута-луны, ы
еее, моя прога работает!!!)))
Ну вообще, ладно. Опуская вопрос реакции на подобные запросы в друзья (серьезно, моя реакция на «У нас похоже фавы, го дружить» будет «Тебе дрочить что ли больше не с кем?»), создание нормальной системы, которая сможет найти близких по духу людей по их фавам — тянет на полноценную весьма кошерную начную работу в каком-нибудь весьма солидном универе (если ты сумеешь убедить полезность этой вещи, которая не заключается в поиске партнеров для дрочки). Проблема в том, что это не банальное «пересечение фавов»:
— ты сознательно исключаешь низкорейтинговые изображения. Да, понятно, что это аппаратное ограничение (про него ниже), но ценность совпадений у абсолютного топа ничтожна (еще тысячи людей поставили фавы, ну и толку с этой инфы?), в то время как ценность совпадения у картинки, которую зафавали вы вдвоем стремится чуть ли не к бесконечности (ну либо это твой твинк). На самом деле не совсем к бесконечности, а то программа рискует зашипперить за 2 единственных фава вхлам заминушенной кривой пикчи в пеинте;
— после прошлого нужно учитывать и возраст изображений, и желательно дату регистрации/активности юзера, чтобы хоть примерно прикидывать вероятность того, что вы видели примерно одинаковый набор картинок и отреагировали одинаково;
— фавы — не единственная точка пересечения, которая технически доступна. Можно опираться еще на фильтр/вотчлист (правда легально это можно делать только в одностороннем порядке, вторую сторону можно только попытаться предсказать по тем же самым фавам), но, опять-таки, не в текущей реализации;
— ты выше писал про теги — это работающий сценарий, но нужно учитывать, что все теги нужно воспринимать по-разному:
— — разброс по фавам в тегах вида solo female, solo male, straight, gay… может тебе дать инфу об ориентации. Если ты делаешь приложение для знакомств, это чертовски важный пункт, лол;
— — доли по персонажам — тоже весьма важный показатель, позволяет выцепить «любимую пони». Тут сложности, как это трактовать, потому что есть риск подраться за вайфу;
— — доли по артерам — просто вкусовщина;
— — и это я перечислил что-то около четверти тегов, а еще есть целый вагон, который тоже дает инфу для размышлений.
По реализации, скажем прямо: качать 18 гигов данных — невероятно пососно, и никакое одиночество не сподвигнет на такое наверное. Скорость работы этого дела… эх.
— тебе дали в руки гребанную БД. Ну используй ее, наконец, они созданы для этой фигни. Самый простой вариант: взять этот дамп, каким-нибудь скриптом выдавить дамп поменьше, с исключительно нужными тебе данными (там будет менее 100 мб, я тебе гарантирую), набросать на коленке приложение с каким-нибудь SQLite под капотом — и оно заведется даже на тапке, и будет работать значительно быстрее. Правда, для сколь либо серьезного анализа все равно придется повозиться, но текущим методом ты это не сделаешь;
— у тебя есть целая бура с целой апишкой с возможность гонять целый апикей, который дает еще кучу информации. Проверить пересечение фавов с конкретным человеком можно даже руками, и это займет не более минуты. Сложно будет проверить пересечение со всеми, да, тут ты уже рискуешь огрести по хлебалу от байта;
— целый простор для промежуточных решений между этими двумя крайностями: от сервера с некоторым кэшем и частью данных, до приложения, которое умеет само ломиться на буру.

Ну и таки нужно учитывать, что все-таки вкусы людей разные, и не стоит на этом слишком акцентироваться. Почти ни у кого из моих друзей вкусы к контенту не совпадают нормально.
А, да, еще нужно учитывать, что все по-разному ставят фавы, кто-то часто, кто-то не очень, и за счет этого тоже можно по-разному учитывать разные виды расхождений и схождений (как крайний случай: пользователь, который фавает вообще все будет на примерно одинаковом расстоянии от всех остальных пользователей. Кроме, возможно, другого такого индивида. Таки вин получится).
(серьезно, моя реакция на «У нас похоже фавы, го дружить» будет «Тебе дрочить что ли больше не с кем?»),

не знаю как тебе, но мне было бы очень приятно, если бы такое кто-то неиронично мне написал.
— ты сознательно исключаешь низкорейтинговые изображения.

У меня нет 100гб оперативки, сорри… и работать будет в 10 раз дольше.
Можно сделать более грубый подсчет (например, учитывать только последние 3 цифры в айди арта), но в таких случаях погрешность поиска будет еще выше, чем исключение низкорейтинговых артов. Я считаю что 300-400 — это адекватная мера ограничения. Понятное дело, что чем выше рейтинг, тем выше шанс, что юзер проголосовал за арт просто потому что он популярный, именно поэтому я не ставлю ограничения в 1к+. Я ещё подумаю как это можно будет оптимизировать, но в лучшем случае удастся опустить значение с 300 до 250, и то не факт.
Я уверен, что поиск по тегам будет более точным — программа будем смотреть не на сами арты, а на теги этих артов. И будет искать юзеров, у кого точно такие же предпочтительные теги.
— после прошлого нужно учитывать и возраст изображений, и желательно дату регистрации/активности юзера, чтобы хоть примерно прикидывать вероятность того, что вы видели примерно одинаковый набор картинок и отреагировали одинаково;

Думаю выгоднее всего будет исключать вообще из поиска тех юзеров, которые не заходили на Буру определенное время. только вот… хранится ли эта графа открыто и если да, то какой срок выбрать? Месяц, год?..
— фавы — не единственная точка пересечения, которая технически доступна. Можно опираться еще на фильтр/вотчлист (правда легально это можно делать только в одностороннем порядке, вторую сторону можно только попытаться предсказать по тем же самым фавам), но, опять-таки, не в текущей реализации;

по сути это и есть теги. которые я описал выше.
— ты выше писал про теги — это работающий сценарий, но нужно учитывать, что все теги нужно воспринимать по-разному:

Я буду теги воспринимать относительно. 2 бита на один тег:
00 — у юзера 0% этого тега в избранном.
01 — у юзера до 1% тега в избранном
10 — у юзера до 5% тега в избранном
11 — у юзера 5% и более этого тега в избранном.
далее все теги побитово умножаются и считается количество единиц. С кем больше всего единиц — с тем у вас наиболее похожие взгляды на теги. или есть более качественные идеи, при условии обязательного ограничения в 1-2 бита на тег?
мне было бы очень приятно, если бы такое кто-то неиронично мне написал.

Потому что ты unicum Саша Флаер! :D
— — разброс по фавам в тегах вида solo female, solo male, straight, gay… может тебе дать инфу об ориентации. Если ты делаешь приложение для знакомств, это чертовски важный пункт, лол;

пойми какое дело… если у юзера 10к артов в избранном, и всего 1 гейский — это еще не повод заносить юзера к геям.
— тебе дали в руки гребанную БД. Ну используй ее, наконец, они созданы для этой фигни. Самый простой вариант: взять этот дамп, каким-нибудь скриптом выдавить дамп поменьше, с исключительно нужными тебе данными (там будет менее 100 мб, я тебе гарантирую), набросать на коленке приложение с каким-нибудь SQLite под капотом — и оно заведется даже на тапке, и будет работать значительно быстрее. Правда, для сколь либо серьезного анализа все равно придется повозиться, но текущим методом ты это не сделаешь;

Я это и делаю! я вычленяю самуцю нужную информацию, удаляю арты ненужные, удаляю юзеров у которых 0 избранных, и оставляю в итоге только самую полезную инфу.
— у тебя есть целая бура с целой апишкой с возможность гонять целый апикей, который дает еще кучу информации. Проверить пересечение фавов с конкретным человеком можно даже руками, и это займет не более минуты. Сложно будет проверить пересечение со всеми, да, тут ты уже рискуешь огрести по хлебалу от байта;

api будет работать в одностороннем порядке. Это будет эффективно если сервис окажется супер-популярным, и многие будут давать мне свой ключ. Тогда да, эта статистика может помочь.
— целый простор для промежуточных решений между этими двумя крайностями: от сервера с некоторым кэшем и частью данных, до приложения, которое умеет само ломиться на буру.

У меня есть идея закешировать попарно вообще всех юзеров после загрузки каждого дампа. Но это будет занимать уйму времени.
пойми какое дело… если у юзера 10к артов в избранном, и всего 1 гейский — это еще не повод заносить юзера к геям.
Естественно, тут все на пропорциях, вероятностях и долях. Если из 10к артов 500 гейских — это уже повод подумать, чтобы занести его туда.

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

api будет работать в одностороннем порядке
Я описал механизм предсказаний, и даже в одностороннем инициативном порядке это поможет.

хранится ли эта графа открыто и если да
Она открыта, но вроде в дамп не попадает

00 — у юзера 0% этого тега в избранном.
01 — у юзера до 1% тега в избранном
10 — у юзера до 5% тега в избранном
11 — у юзера 5% и более этого тега в избранном.

Это будет очень плохо работать с тегами артеров, которые имеют в среднем невысокие значения, и даже до 10% может быть погрешность. Нужно именно рожать какую-то комплексную логику, не завязанную на битах.
неиндексируемую медленную хрень.

я храню все данные либо в dict(), в котором используется хеш-индексация, либо array.array, который является с++ массивом с индексацией через указатели, где длина каждого элемента массива четко определена. Получение элемента по индексу в обоих случаях работают как o(1), как и в базе.
Окей, уточню формулировку, либо неиндексируемую медленную хрень (те файлики), либо невероятно жручую крайне быструю хрень
невероятно жручую крайне быструю хрень

Чтобы программа работала как сервер, быстрота должна быть в приоритете — либо ты за считанные секунды считываешь всё с оперативки, либо делаешь запрос к базе чтобы получить сотни тысяч фавов, которые явно займут время. Я уже на 100% уверен, что прогу придется переписать на с++, чтобы сэкономить в два раза оперативу, и тем самым получив возможность снова нагрузить её в два раза, снизив минимальный порог рейтинга.
Реальность в том, что тебе не нужны эти сотни тысяч фавов. Вся твоя логика делается одним запросом (на самом деле тут три, чтобы в один присест все забрать, и это далеко не оптимальный запрос, его можно оптимизировать)
sеlect
  (sеlect count(1) from FAVES where USER_ID = :user1) as User1FavesCount,
  (sеlect count(1) from FAVES where USER_ID = :user2) as User2FavesCount,
  (sеlect count(1) from FAVES where USER_ID in (:user1, :user2)) as BothFavesCount<br />
from dual;

И оно будет работать на ебучем тапке настолько быстро, что тебе даже мысли не придет переходить на плюсы.
user2
ты ведь понимаешь, что придется пробежаться по всем юзерам, подставив их имена в user2? Один этот запрос — да, быстро. но когда тебе придется сделать этот запрос 300к раз — ну, такое…
БД писали умные люди, они умеют в кэши и индексы.
sеlect
  u.NAME as User2Name,
  (sеlect count(1) from FAVES f where f.USER_ID = :user1) as User1FavesCount,
  (sеlect count(1) from FAVES f where f.USER_ID = u.ID) as User2FavesCount,
  (sеlect count(1) from FAVES f where f.USER_ID in (:user1, u.ID)) as BothFavesCount
from USERS u where u.ID <> :user1;
Я верю что в кеш и индексы они умеют, но получение данных из стороннего, хоть и быстрого, сервиса, хранящегося на жеском диске или даже ssd, в любом случае будет дольше, чем если эта информация хранится в родном индексированном формате прямо под рукой в оперативке
В тебе нет рациональности и умения выбрать правильный подход, и от этого ты огребаешь:
— хранить вагон данных в опере на продуктиве оправдано пожалуй только для ну нереально жирных математических рассчетов с огромным количеством данных, которые адски просядут на чем угодно еще, и которые выполняются однократно;
— любой руководитель, когда будет стоять перед выбором «отгрохать веб-сервис, который выплюнет ответ за миллисекунды, но потребляет сотни гигов оперы», либо «отгрохать веб-сервис, который влезет в полгига оперы списанного десять лет назад сервера и выдает ответ на 10 секунд дольше» выберет второе…
— потому что ты делаешь веб-сервис разового использования. Вероятность того, что пользователь в том же месяце воспользуется им повторно ничтожна. Если ему придется подождать не 5 секунд (учитывай время полета пакетов по сети), а 15 секунд, он не очень обидится;
— ты сам же влетишь в это ограничение, когда начнешь развивать логику. Оставь оперу для высокоуровневых вычислений, выборку возложи на системы, которые созданы для этого.
Мне сейчас предложили идею, следуя которой, в теории, на плюсах будет потребляться максимум 2 гига для вообще всех артов. Я попробую её реализовать, если не получится — тогда перейду на базу.
Я понимаю, что когда речь идет про десятки и сотни гигабайт — то выбор всегда будет в пользу базы. Но в контексте единиц гигабайт, разница между оперативкой и ssd ничтожно мала в абсолютных значениях.
@andreymal, может ты в курсе, мне не давало отписать коммент, пока я все е в sеlect не поменял на русские, чзх? Это же слишком примитивно как средство защиты.
Этот чёртов Cloudflare ещё и юзерагент python urllib банит, ага

ls -l ещё тоже нельзя написать (можешь в предпросмотре проверить) (зато rm -rf /* почему-то можно)
Видимо, возможность просрать все данные они считают менее опасной, чем спалить все данные.
Иногда(когда коммерческая информация) так и есть.
У табуна очень интересный вордфильтр, он действительно не пропускает некоторые популярные в коде слова (вероятно, подразумевается, что ими можно что-то похакать… но я крайне в этом сомневаюсь =) — и самое главное, не говорит, почему, просто «произошла ошибка» и всё.
что ими можно что-то похакать

Собственно, именно такими лазейками Табун и хакнули летом 2016 года. Думаю админы не хотят лишний раз испытывать судьбу.
Ну если там нет тупых ошибок типа «вы правда назвали своего сына „Robert'); DROP TABLE Students; --“?», то похакать не получится (а если есть — то и сейчас можно).
Мне кажется такую штуку лучше оформлять как веб сервис)
подскажешь как лучше всего хранить эти данные для сервера? на данный момент поиск по юзеру занимает 6 минут, что несоизмеримо много для веб. Это всё ещё приемлемо, учитывая СКОЛЬКО там данных, но никто не будет ждать пока страница загрузится. тем более юзер будет не один…
Собственно, использовать базу данных с индексами, а не файлы )
И получать информацию ajax запросом.
Т.е. поднимаешь постгрес и в нем базу данных с дерпибуры (там в начале написано как поднять). Меняешь скрипт для работы с базой данных, а не с файликами. Это должно очень хорошо повысить скорость работы.
А потом просто делаешь страничку, на которой поле для ввода ника и кнопка «найти похожих пользователей», или что-то такое.
При нажатии на кнопку делается запрос к скрипту, он естественно занимает время (хоть и меньше чем 6 минут), на странице пока анимация того что скрипт делает свою работу. И когда данные готовы выводишь их.
Можно если пользователь уже ушел со страницы на другую проиграть звук, например.
он естественно занимает время

ты уверен, что он будет занимать меньше времени, чем если хранить все данные в c++ в формате std::map<int, std::vector>
Табун не дает дописать int в вектор… тупо стирает оттуда, втф
при условии что std::map<int, std::vector(int)> будет занимать около 800 мегабайт
М, у тебя там эффективные… Вот тут тогда не уверен, но как минимум оно не будет каждый раз парсить.
Проверить как минимум стоит, оно не особо сложно делается )
Меняешь скрипт для работы с базой данных, а не с файликами. Это должно очень хорошо повысить скорость работы.
Кстати, плюсую: нормальные базы работают даже не в разы, а на порядки быстрее текстовых файликов.
Ты не понял — на данный момент все данные для анализа хранятся как объекты класса array. Это никак не связано ни с базой, ни с текстовыми файлами.
Ба, Лунавод, Стасян, Андрей в одном треде! Ещё Орхида не хватает для компании. )))
Все великие кодеры Табуна собрались в одном месте, нужно еще Злюку в идеале. И NTFS-а.
У меня получилось! Теперь переписанная на с++ программа хранит данные о всех картинках (а не только с рейтингом 300+), и поиск происходит мгновенно. И занимает всего 1 гиг оперативки. Так же добавлен новый функционал, позволяющий настраивать предпочтения — искать среди более «нишевых» или более «попсовых» брони (то есть, у поиска будет изменяться чувствительность к менее заплюсованным или более заплюсованным артам среди общего избранного)
Какой алгоритм если не секрет?
Скоро я выложу исходник оптимизированной программы. В новой версии подсчет даже проще, чем то что сейчас. Но я честно не знаю как называется такой алгоритм.
Мм, занятная штука. Я на дёрпибуре не зареган, ergo не могу проверить на себе, но на первый взгляд кажется достаточно интересной вещью (фактически задача сортировки декартового произведения множества пользователей на множество тегов по суммарному статистическому весу строчки с тегами).

Кстати, Флаер, не хочешь ещё одну полезную для брони идейку подкину?

Про поиск поней по цвету шёрстки и гривы на базе вот этого списка.
Я бы сам накодил, но некогда, плюс там много нетривиальностей — например, список создаётся на этой странице динамически, и потому каким-нибудь fetch-ем его не получить (вероятно, нужно пилить юзерскрипт и запускать его по кнопке на уже сгенерённой странице); или то, что jQuery не умеет нормально сортировать по численным значениям; или то, что нужно каким-нибудь хитрым алгоритмом вычислять цветовую дистанцию от выбранного цвета. Очевидно, надо пользователю предлагать выбор из небольшого количества цветов — порядка восьми, типа красный, жёлтый, зелёный, циан, синий, фиолетовый, белый, чёрный, но я не уверен, что дистанция будет адекватно вычисляться простым трёхмерным расстоянием типа sqrt((r-r0)^2 + (g-g0)^2 + (b-b0)^2).

Если вдруг тебе такая штука будет интересна — то думаю, многим бы результат пригодился бы =)
Если не интересна — не страшно, когда-нибудь сам напишу, наверное
я не уверен, что дистанция будет адекватно вычисляться простым трёхмерным расстоянием типа sqrt((r-r0)^2 + (g-g0)^2 + (b-b0)^2).

HSV для такого должен неплохо подойти
Там тоже не всё так просто — явно нужно какие-то коэффициенты вводить, потому что, например, разброс в 15% по насыщенности будет практически незаметен, а 15% по оттенку сделают красный жёлтым, а зелёный — голубым.
Пока что идея меня не зацепила, сорри. Возможно позже обращу на это внимание.
Ну ок, не страшно, может, сам как-нибудь накодю =)
> но я не уверен, что дистанция будет адекватно вычисляться простым трёхмерным расстоянием типа sqrt((r-r0)^2 + (g-g0)^2 + (b-b0)^2)

в rgb — не особо. чтобы евклидова метрика «работала» тебе нужно перцептивно равномерное цветовое пространство. можно попробовать lab, там есть проблемы, но для твоих целей должно быть ок. ещё можно использовать квазиметрику (нет симметричности) $\delta E$. и то и другое уже реализовано в chroma js.
Вот, кстати да, спасибо. Я тоже об этом думал (но пока что не искал соответствующие либы).
я хз, для чего кому-то это может быть нужно, но не понимать, зачем физикам что-то нужно, это, наверное, ок.

держи, scitwi.gitlab.io/color-matcher
работает в хроме и, предположительно, в фф
ААА! Это вот прямо то, что мне было нужно! =)
Спасибо тебе огромное, что довёл эту идею до реализации, я думаю, не только мне, но и многим другим эта вещь тоже пригодится =)
В FF работает, подтверждаю.
Может по старинке? Там посты мол брони 26 лет, живу у минске ищу пегасосестру для создания табунчика
Ну окей… попробуем.я Девушка, ищу друзей для общения и не только, пол не важен, я люблю: клопоту, даркоту, Шиппинг разный в основном кобылок.сама я с Украины, я типа новенькая в фандоме…
Меня терзают смутные сомнения, что я тебя видел в чатике ещё того ОРТ, лол =) Впроче, скорее всего, я ошибаюсь, мне часто по манере речи кажутся похожими совсем разные люди
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.