Если сравнивать картинки до/после, там хорошо заметен шум добавляемый на изображение. Скорее всего минимальное преобразование изображений сломает эту защиту, на reddit уже пишут, что защита обходится удалением шума.
Если вы знаете какую-то компанию или людей, делающих языки, компиляторы и другой подобный инструментарий в нашей стране, упомяните их в комментариях.
Я делаю языки и компиляторы. По большей части это связки вида: language server (парсер, индекс, подсветка, переходы и т.д) + анализатор/исполнитель синтаксического дерева + экспорт/импорт. Сервера я пишу на Java, клиенты на VSCode, но я ими не занимаюсь.
Пойдет по кратчайшему пути. Если этот путь пройдет под диакритикой - отрежет ее от буквы. Чтобы этого избежать можно добавить штрафы за прохождение под островами или за расстояние от центра интервала, чтобы диакритики было выгоднее обходить сверху.
Я бы поставил эксперимент на нескольких картинках, возможно будет нормально работать и без дополнительных штрафов.
Как-то у меня была задача увеличения интервалов между строками на отсканированных изображениях, нужно было растянуть картинку по вертикали сохраняя пропорции букв. Итеративно пришел к такому алгоритму:
Рассчитываем среднее значение в каждой строке пикселей. Там где больше светлого будет междустрочным интервалом, где темного - текстом;
Выбираем из полученных средних значения больше порога. Подбирается на глаз в зависимости от качества картинок и шрифтов;
Находим путь между левой и правой границами изображения для каждой группы белых пикселей, если в группе их больше порога (подбивается в зависимости от картинок и их качества);
Добавляем пустое пространство по всем полученным путям.
Пример на картинке из статьи
Здесь каждая синяя линия - один шаг алгоритма. Пути нарисованы от руки.
С чеками, скорее всего, высота строк всегда будет одинаковой. Поэтому можно строить пути отступая нужное число пикселей от строки, состоящей из минусов.
У меня что-то подобное на базе API банка сделано. Когда я пополняю счет или приходят дивиденды просто запускаю скрипт, он считает сколько чего докупить и выдает запрос на выставление заявок. Сначала тоже делал в табличке, потом понял, что трачу очень много времени на перенос в нее цифр и решил автоматизировать.
Правильно ли я понимаю, что есть две версии библиотеки: одна использует только скалярный код, вторая RVV 0.7.1? Если это так, не могли бы вы привести аналогичное сравнение производительности для этих версий библиотеки, интересно какой эффект дает использование векторных инструкций.
Есть ли вас или еще кого-то у планы по добавлению поддержки RVV 0.7.1 в LLVM? Насколько я понимаю там не очень большая разница в командах, зато код будет работать на многих доступных сейчас платах RISC-V.
И еще каким образом у вас вычисляются функции вроде exp и log в векторной реализации библиотеки?
Возможно я ошибаюсь, но, насколько я понимаю, их концепцию: в Nanite они сделали что-то аналогичное адаптивному LOD для земли, но вместо heightmap-а использовали расстояние до базовой модели и переложили генерацию треугольников на видеокарту. А цветные кусочки - это те самые heightmap-ы на которые разбита моделька и которые использует шейдер для генерации треугольников.
А вы не пробовали использовать SIFT дескрипторы чтобы сравнивать картинки? На подобных задачах они должны хорошо работать заодно позволяют визуализировать за что цепляется алгоритм в отличие от нейросетей.
Загрузку процессора сейчас посмотрел, действительно меньше половины. Не могу сказать почему так получается, я пока плохо разбираюсь в том какие параметры и где можно менять.
По поводу видеокарты - у нее во время вывода загрузка GPU и VRAM в районе 100%, она скорее всего работает. Вывод о недостатке VRAM я сделал из того, что было написано в исключении когда я пробовал всю модель положить в видеопамять.
Исключение
torch.cuda.OutOfMemoryError: HIP out of memory. Tried to allocate 112.00 MiB. GPU 0 has a total capacity of 7.98 GiB of which 86.00 MiB is free. Of the allocated memory 7.64 GiB is allocated by PyTorch, and 79.70 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_HIP_ALLOC_CONF=expandable_segments:True to avoid fragmentation. See documentation for Memory Management (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)
С опцией expandable_segments:True работает работает аналогично.
Скорее всего у вас на видеокарте они в формате f16 лежат и частично скидываются в оперативную память, а на процессоре так считать не получится все нужно держать в памяти в f32. На Stable Diffusion от Automatic1111 для этого есть специальные опции: --no-half, --medvram, --medvram-sdxl, --lowvram, --lowram. У меня 8Гб на видеокарте, иногда при использовании ControlNet приходится этими опциями жонглировать, чтобы памяти хватало.
У меня специальная симка для таких собирателей. Стоит в простом телефоне, который я включаю только для того, чтобы получить SMS, в остальное время я им не пользуюсь.
Я бы в список ухудшающих объектов добавил тюрьмы и СИЗО, мне бы не хотелось видеть их ежедневно. И мне лично не хотелось бы жить рядом с церквями и мечетями, из-за постоянного звона колоколов.
В данном случае для обработки столкновений с уровнем можно использовать двумерный массив, а движущиеся объекты сортировать по (x, y) и находить потенциальные пересечения практически одним проходом (алгоритм sweep and prune). Если я правильно понимаю, то столкновения можно проверять только для пересечения персонажа с врагами и бонусами, и расставлять флаг взрыва на сетке чтобы убивать всех наступивших на этот флаг.
Чтобы не быть голословным пример из моей игры
Красные квадраты - обозначают твердые части уровня, в игре это просто массив булевых значений. Столкновение проверяется через обращение к элементу массива (в зависимости от размера объекта может быть и больше обращений, например для босса - 8), если значение true - значит есть столкновение и нужно рассчитать импульс для выталкивания. Выталкивание считается исходя из того, что границы элементов сетки всегда целые числа, поэтому можно просто отбрасывать целую часть AABB и получить смещение. (или 1 - смещение для левой границы).
Мне кажется, что нужно сравнивать процессоры в одинаковых условиях. Если уж решено было оптимизировать модель под Эльбрус, то имеет смысл так же оптимизировать ее под Ryzen и сравнивать уже оптимизированные модели.
Недавно я обучал нейросеть для автоматизации лайков в приложениях для знакомств. В процессе обучения разметил несколько тысяч женских лиц. По ощущениям для меня красивыми лицо делали два фактора: близость к среднему лицу (например у половины глаза далеко посажены, у половины - близко, посредине - красиво), и отсутствие косметических дефектов на коже. А симметрия была скорее следствием этих факторов.
Думаю такой стиль диалога для моего возраста (35 лет) не очень подходит, но ради эксперимента попробую, терять все равно нечего.
На самом деле я давно ищу какие-то базы успешных диалогов/переписок с девушками. К сожалению, ничего толкового найти не смог. В основном попадаются всякие ролики/учебники для пикаперов с парой фраз вместо привета и все.
Прямых ссылок не дам, но есть исследования от okcupid, можете по запросу "okcupid statistics" поискать картинки, там много разных графиков (для других приложений аналогично можно найти). Есть от известного хаба статистика по предпочтениям, они каждый год что-то новое публикуют. По поводу шансов, в США есть такая штука как "looksmaxxing" - это попытка понять и как-то описать каких мужчин выбирают женщины, для женщин видел только простейшие правила.
Я уже третий год в тиндере и аналогичных сайтах сижу. Уже многое испробовал, и что программист писал, и на фото сессию ходил. И не замечаю, чтобы женщины хотя бы пытались диалог поддержать, не говоря о желании встретиться. И с приходом известных событий я изменений не увидел.
Если сравнивать картинки до/после, там хорошо заметен шум добавляемый на изображение. Скорее всего минимальное преобразование изображений сломает эту защиту, на reddit уже пишут, что защита обходится удалением шума.
Я делаю языки и компиляторы. По большей части это связки вида: language server (парсер, индекс, подсветка, переходы и т.д) + анализатор/исполнитель синтаксического дерева + экспорт/импорт. Сервера я пишу на Java, клиенты на VSCode, но я ими не занимаюсь.
Пойдет по кратчайшему пути. Если этот путь пройдет под диакритикой - отрежет ее от буквы. Чтобы этого избежать можно добавить штрафы за прохождение под островами или за расстояние от центра интервала, чтобы диакритики было выгоднее обходить сверху.
Я бы поставил эксперимент на нескольких картинках, возможно будет нормально работать и без дополнительных штрафов.
Как-то у меня была задача увеличения интервалов между строками на отсканированных изображениях, нужно было растянуть картинку по вертикали сохраняя пропорции букв. Итеративно пришел к такому алгоритму:
Рассчитываем среднее значение в каждой строке пикселей. Там где больше светлого будет междустрочным интервалом, где темного - текстом;
Выбираем из полученных средних значения больше порога. Подбирается на глаз в зависимости от качества картинок и шрифтов;
Находим путь между левой и правой границами изображения для каждой группы белых пикселей, если в группе их больше порога (подбивается в зависимости от картинок и их качества);
Добавляем пустое пространство по всем полученным путям.
Пример на картинке из статьи
Здесь каждая синяя линия - один шаг алгоритма. Пути нарисованы от руки.
С чеками, скорее всего, высота строк всегда будет одинаковой. Поэтому можно строить пути отступая нужное число пикселей от строки, состоящей из минусов.
У меня что-то подобное на базе API банка сделано. Когда я пополняю счет или приходят дивиденды просто запускаю скрипт, он считает сколько чего докупить и выдает запрос на выставление заявок. Сначала тоже делал в табличке, потом понял, что трачу очень много времени на перенос в нее цифр и решил автоматизировать.
Правильно ли я понимаю, что есть две версии библиотеки: одна использует только скалярный код, вторая RVV 0.7.1? Если это так, не могли бы вы привести аналогичное сравнение производительности для этих версий библиотеки, интересно какой эффект дает использование векторных инструкций.
Есть ли вас или еще кого-то у планы по добавлению поддержки RVV 0.7.1 в LLVM? Насколько я понимаю там не очень большая разница в командах, зато код будет работать на многих доступных сейчас платах RISC-V.
И еще каким образом у вас вычисляются функции вроде exp и log в векторной реализации библиотеки?
Было бы интересно узнать, есть ли какая-то корреляция успеха в испытаниях с полом игроков.
Возможно я ошибаюсь, но, насколько я понимаю, их концепцию: в Nanite они сделали что-то аналогичное адаптивному LOD для земли, но вместо heightmap-а использовали расстояние до базовой модели и переложили генерацию треугольников на видеокарту. А цветные кусочки - это те самые heightmap-ы на которые разбита моделька и которые использует шейдер для генерации треугольников.
А вы не пробовали использовать SIFT дескрипторы чтобы сравнивать картинки? На подобных задачах они должны хорошо работать заодно позволяют визуализировать за что цепляется алгоритм в отличие от нейросетей.
Загрузку процессора сейчас посмотрел, действительно меньше половины. Не могу сказать почему так получается, я пока плохо разбираюсь в том какие параметры и где можно менять.
По поводу видеокарты - у нее во время вывода загрузка GPU и VRAM в районе 100%, она скорее всего работает. Вывод о недостатке VRAM я сделал из того, что было написано в исключении когда я пробовал всю модель положить в видеопамять.
Исключение
torch.cuda.OutOfMemoryError: HIP out of memory. Tried to allocate 112.00 MiB. GPU 0 has a total capacity of 7.98 GiB of which 86.00 MiB is free. Of the allocated memory 7.64 GiB is allocated by PyTorch, and 79.70 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_HIP_ALLOC_CONF=expandable_segments:True to avoid fragmentation. See documentation for Memory Management (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)
С опцией
expandable_segments:Trueработает работает аналогично.Вчера игрался с этой моделью. На Ryzen 7 2700X с запросом "определение человека с сильным характером":
saiga_mistral_7b- в среднем 10 минут;q2_K.gguf- примерно 20 секунд;q4_K.gguf- примерно 30 секунд;q8_0.gguf- примерно минута.На видеокарте Radeon RX 7600 через ROCm тоже около 10 минут из-за того, что на ней памяти под модель не хватает.
Скорее всего у вас на видеокарте они в формате f16 лежат и частично скидываются в оперативную память, а на процессоре так считать не получится все нужно держать в памяти в f32. На Stable Diffusion от Automatic1111 для этого есть специальные опции:
--no-half,--medvram,--medvram-sdxl,--lowvram,--lowram. У меня 8Гб на видеокарте, иногда при использовании ControlNet приходится этими опциями жонглировать, чтобы памяти хватало.У меня специальная симка для таких собирателей. Стоит в простом телефоне, который я включаю только для того, чтобы получить SMS, в остальное время я им не пользуюсь.
Я бы в список ухудшающих объектов добавил тюрьмы и СИЗО, мне бы не хотелось видеть их ежедневно. И мне лично не хотелось бы жить рядом с церквями и мечетями, из-за постоянного звона колоколов.
В данном случае для обработки столкновений с уровнем можно использовать двумерный массив, а движущиеся объекты сортировать по
(x, y)и находить потенциальные пересечения практически одним проходом (алгоритм sweep and prune). Если я правильно понимаю, то столкновения можно проверять только для пересечения персонажа с врагами и бонусами, и расставлять флаг взрыва на сетке чтобы убивать всех наступивших на этот флаг.Чтобы не быть голословным пример из моей игры
Красные квадраты - обозначают твердые части уровня, в игре это просто массив булевых значений. Столкновение проверяется через обращение к элементу массива (в зависимости от размера объекта может быть и больше обращений, например для босса - 8), если значение
true- значит есть столкновение и нужно рассчитать импульс для выталкивания. Выталкивание считается исходя из того, что границы элементов сетки всегда целые числа, поэтому можно просто отбрасывать целую часть AABB и получить смещение. (или1 - смещениедля левой границы).PS: красные каракули внизу - это эффекты.
Мне кажется, что нужно сравнивать процессоры в одинаковых условиях. Если уж решено было оптимизировать модель под Эльбрус, то имеет смысл так же оптимизировать ее под Ryzen и сравнивать уже оптимизированные модели.
Недавно я обучал нейросеть для автоматизации лайков в приложениях для знакомств. В процессе обучения разметил несколько тысяч женских лиц. По ощущениям для меня красивыми лицо делали два фактора: близость к среднему лицу (например у половины глаза далеко посажены, у половины - близко, посредине - красиво), и отсутствие косметических дефектов на коже. А симметрия была скорее следствием этих факторов.
Думаю такой стиль диалога для моего возраста (35 лет) не очень подходит, но ради эксперимента попробую, терять все равно нечего.
На самом деле я давно ищу какие-то базы успешных диалогов/переписок с девушками. К сожалению, ничего толкового найти не смог. В основном попадаются всякие ролики/учебники для пикаперов с парой фраз вместо привета и все.
Прямых ссылок не дам, но есть исследования от okcupid, можете по запросу "okcupid statistics" поискать картинки, там много разных графиков (для других приложений аналогично можно найти). Есть от известного хаба статистика по предпочтениям, они каждый год что-то новое публикуют. По поводу шансов, в США есть такая штука как "looksmaxxing" - это попытка понять и как-то описать каких мужчин выбирают женщины, для женщин видел только простейшие правила.
Я уже третий год в тиндере и аналогичных сайтах сижу. Уже многое испробовал, и что программист писал, и на фото сессию ходил. И не замечаю, чтобы женщины хотя бы пытались диалог поддержать, не говоря о желании встретиться. И с приходом известных событий я изменений не увидел.