Упрашивал ChatGPT нарисовать мне картинку с человеком. Ни в какую! Отказывается!
Сегодня с помощью ChatGPT генерировал картинку к Норм ЦРМ.
Я добавил мета-теги, заголовки на двух языках. Ну и картинку, которая будет подтягиваться, когда кто-то будет делиться ссылкой на проект.
Попросил нарисовать фрилансера-одиночку за уютным домашним рабочим местом. И тут — хопа — отказ. Мол, это не соответствует нашим политикам.
Тогда попросил нарисовать человека, лица которого мы не видим. Просто фигуру. Снова отказ.
Затем попросил нарисовать антропоморфного кота. И тоже нельзя.
Я удивился. Раньше никаких подобных ограничений не было. В итоге попросил сгенерировать картинку без людей, а сам пошёл разбираться, какая нейронка мне теперь подойдёт для этих целей вместо ChatGPT.
Если что, использую пятую версию с подпиской Plus.
—— Апдейт:
В комментариях пишут, что никаких ограничений нет.
Я попробовал сгенерировать в новом диалоге — и тоже ограничений не оказалось.
А вот внутри папки с проектом — не разрешает по какой-то причине.
RFC 9828: стандарт, который, странным образом, опоздал лет на двадцать
JPEG 2000, появившийся ещё в начале нулевых, давно используется в задачах, где требуется высокое качество изображения, а RTP как транспорт для данных реального времени уже более двадцати лет обеспечивает надёжность. Однако, и это удивительно, всё это время отсутствовал формализованный стандарт, позволяющий передавать JPEG 2000 с минимальной задержкой, по кускам кадра, не дожидаясь его полной готовности, — и лишь в 2025 году он был наконец принят. Можно только гадать, почему в мире, где запускают ракеты в космос по подписке, инженеры продолжали смиренно ждать, пока кадр целиком упадёт в буфер.
Теперь же, с появлением RFC 9828, ситуация меняется: простое на первый взгляд решение — передавать кадр частями, а не целиком, — становится официальной нормой. Как только кодер начинает производить данные, пакеты уже могут быть отправлены в сеть, а приёмник, не дожидаясь окончания всего кадра, начинает сборку изображения. И именно это означает, что впервые JPEG 2000 становится пригодным для таких сценариев, где маркетинговый термин «low latency» оборачивается критическим требованием: телевещание в прямом эфире, дистанционная хирургия или работа со сверхкачественным изображением в реальном времени.
Вместо прежнего порядка «сначала кадр, затем поток» появляется обратный — «сначала поток, затем кадр». Благодаря этому сеть получает ту самую гибкость, о которой раньше говорили как о недостижимой: лишние уровни разрешения и качества можно отбрасывать на лету, даже не вскрывая содержимое. Приёмник, в свою очередь, обретает resync-точки, благодаря которым потеря пары пакетов больше не превращается в катастрофу, а разработчики, наконец, могут избавиться от бесконечных костылей, изобретённых в обход RFC 5371.
Выгоды для бизнеса очевидны, хотя каждый сектор формулирует их по-своему. В телевидении по IP режиссёр теперь видит кадр практически сразу, а не спустя полсекунды, и значит — работа в реальном времени перестаёт быть фикцией. В медицине появляется возможность стримить эндоскопию или МРТ с качеством вплоть до lossless и при этом не терять драгоценные секунды, от которых зависит исход операции. Кинопроизводство перестаёт таскать гигабайты по дискам, потому что мастер-кадры наконец-то могут пересылаться по сети. Даже государственные сервисы, включая суды и видеоконференции, приобретают шанс выглядеть не как мем из 2008 года, а как инструмент XXI века.
Да, пока это лишь бумага. Но, как обычно бывает: сначала RFC, затем — первые SDK и FPGA-решения, а чуть позже — перепакованные в отраслевые документы SMPTE и ITU стандарты. В горизонте двух-трёх лет мы увидим первые реальные внедрения в телевидении и медицине, в горизонте пяти — широкое распространение. А дальше, возможно, даже lossless-видеозвонки без лагов перестанут казаться фантастикой.
RFC 9828 — это не просто ещё один формат. Это признание индустрии в том, что ждать конца кадра всё это время было, мягко говоря, глупо.
Это серия постов от идеи ImageSorcery до 100+ звёзд на гитхабе и 100+ ежедневных установок с PyPI.
В прошлый серии мы с Gemini 2.0 flash определили стек: python, OpenCV, Ultralytics и никакого ImageMagic.
Начал я как обычно с малого. В Cline попросил своего любимого бесплатного друга Gemini накидать скрипт на python который получает данные о размере (ширина, высота в пикселях) изображения. Дальше больше - скрипт crop который обрезает изображение по указанным аргументам. С последним пришлось повозиться и даже переключиться на Pro версию, благо она тоже бесплатная, пусть и с жёсткими лимитами.
😎 one shot изи катка: detect_objects находит координаты объектов, а crop_objects их вырезает
PoC готов, можно приступать к реализации MVP.
Как вы помните, в python я тот ещё джун. Так что я не стал рисковать своим любимым бесплатным Gemini flash и даже pro, а сразу переключился в бесплатный браузерный Claude (лучший ии-кодер что тогда, что сейчас) и попросил дать мне подробнейшую инструкцию по разворачиванию проекта который будет имплементировать простейший hello world MCP сервер.
Нет смысла ваншотить такой проект за раз даже с Claude Opus 4.1. Что он не вывезет, что я не осилю осознать все нюансы за один заход. По этому предпочитаю действовать по комплиментарным шагам, на каждом из которых получать работающий продукт с небольшими изменениями, пока не получу финальный результат.
Написание инструкции - задача с нечётким ТЗ. Такую никогда нельзя пытаться делать ваншотом. Поэтому сперва получаю первую версию по максимально абстрактному промпту, но дав ей столько контекста сколько смог насобирать в интернете и своей голове. А затем по шагам вычитываю - прошу внести исправления - снова вычитываю - снова прошу исправить и так по кругу пока не получаю результат который я понимаю и к которому у меня нет претензий.
И так инструкция готова, закидываю её в Cline + Gemini flash и ... получаю ошибку активации. Вы же помните что в python я джун и понятия о venv не имею? Даю ему шанс исправить ошибку самостоятельно, но бесполезно - он не справляется. Откатываю всё назад, переключаю модель на Gemini Pro - результат тот же. Плюю на экономию, переключаю модель на Claude Sonnet - результат тот же, но оно сожрало 3 бакса 🤬
Плюю на этих бестолковых ИИ и беру дело в свои руки. Рано железякам нас ещё заменять!
Пол дня бесполезного рыскания по stack overflow и дебага, во время которого я случайно обнаружил, что venv активируется если git bash terminal открыт в отдельном окне, а не внутри VSCode. Оказывается эта шарманка будучи запущенной внутри IDE в пути C:\Users\titulus\work сочетание \t воспринимает как знак табуляции из-за чего пытается активировать venv в C:\Users itulus\work 😵💫
Очевидного решения или даже упоминания этого бага я не обнаружил, так что просто уехал со всем своим проектом в WSL, благо VSCode отлично с ним работает. В Linux окружении, разумеется, таких проблем не возникло. Cline Gemini flash ваншотом по той самой инструкции от Claude создал MCP сервер, самостоятельно к нему подключился (вот за это я его обожаю) и проверил.
Я завёл git репозиторий и закоммитил initial commit. Первый шаг сделан ✅
Это серия постов от идеи ImageSorcery до 100+ звёзд на гитхабе и 100+ ежедневных установок с PyPI.
В прошлый раз мы выяснили, что при правильной настройке бесплатных инструментов, бесплатная LLM Gemini может оказаться не хуже Claude в написании документации. И закончили на вопросе, почему никто раньше не привязал MCP к ImageMagic?
А вот почему
Первым делом после звонка с Системным Аналитиком я дал Cline в своём VSCode право на запуск команд в терминале. Затем взял первый попавшийся скриншот мобильного приложения и попросил вырезать NavBar используя ImageMagic. Gemini flash вырезал какую-то случайную часть экрана.
crop "на глаз"
Я переключился на Gemini pro - результат тот же. o3 от OpenAI и Sonnet от Anthropic также облажались.
Долго думал. Я знал что все эти модели мультимодальные и наверняка знают что такое NavBar. Тут явно что-то не сходилось. Я полез раскрывать свёрнутые секции их размышлений и обнаружил что:
Все они понимают, что изображено и “видят” NavBar.
Никто из них не способен вычислить точные координаты этого NavBar.
Они даже размеров изображения не знают.
Из-за чего все они действовали наугад.
Оказывается LLM не умеют определять точные координаты объектов, которые они видят, не говоря уже про их точную геометрию.
В этом и крылся ответ на вопрос “а чего раньше это никто не сделал?”.
С этой дилеммой я пошёл к Gemini. Сокращённая переписка:
👤: порекомендуй мне 5 - 10 пакетов для распознавания изображений на python моя задача - определять координаты объектов для будущего crop ИИ: Pillow, OpenCV, scikit-image, TensorFlow Object Detection API, Detectron2, YOLO, Tesseract OCR, SimpleCV, imutils. Рекомендации: 1) Начните с OpenCV или scikit-image. 2) Если вам нужна более высокая точность или нужно распознавать определенные типы объектов, рассмотрите TensorFlow Object Detection API, Detectron2 или YOLO. 3) Используйте Pillow для загрузки, сохранения и предварительной обработки изображений. 4) Используйте imutils для упрощения работы с OpenCV. 5) Если вам нужно распознавать текст, используйте Tesseract OCR.
👤: расскажи подробней про opencv imutils pytorch и yolo 🤖: - OpenCV - это фундаментальная библиотека для компьютерного зрения, предоставляющая широкий спектр алгоритмов для обработки изображений и обнаружения объектов. - imutils - это набор удобных функций, которые упрощают работу с OpenCV. - PyTorch - это мощный фреймворк машинного обучения, который можно использовать для построения и обучения сложных моделей обнаружения объектов. - YOLO - это семейство алгоритмов обнаружения объектов в реальном времени, известных своей скоростью и точностью.
👤: важный момент. я не хочу обучать модели сам. мне нужен готовый инструмент 🤖: Начните с OpenCV + YOLO от Ultralytics
Как можно заметить, я не силён в python от слова совсем 😅. Но я выбрал его, потому что осведомлён о его большой экосистеме инструментов ML в общем и компьютерного зрения в частности.
И так стек найден. И с удивлением для меня, места для ImageMagic в нём не нашлось, ведь все необходимые инструменты для обработки уже есть в OpenCV.
А что стало с названием ImageWizard?
Тут всё банально. Я погуглил - это название уже занято приложением в сфере обработки изображений с ИИ 🤷. Пришлось найти незанятое. Но постарался оставить отсылку на ImageMagic
ImageSorcery 01 - Как я свой open source вайбкодил
Скажу честно, я хотел написать статью, для того чтобы рассказать о своём проекте ImageSorcery MCP. Но не хотелось писать рекламный BS о том какой он крутой. Хотелось сделать месседж более личным и искренним. Так статья превратилась в серию постов-заметок о всех тех граблях инструментах и практиках, которые мне удалось попробовать на пути от идеи до 100+ звёзд на гитхабе и ~100 ежедневных установок с pypi. А так как я фанатик экономии, весь стек в основном бесплатный (включая LLM) и часто не самый популярный.
Рост звёзд на гитхабе
В компании где я работаю, у меня сложилась репутация, как это принято сейчас говорить, ИИ-энтузиаста. Из-за чего ко мне однажды обратилась Системный Аналитик, которая только начала внедрять RooCode и столкнулась с какой-то проблемой полнейшего тупняка ИИ. Бесплатная веб версия Claude на раз два превращала Верхнеуровневые Бизнес Требования заказчика в детально проработанное Техническое Задание. Но копировать туда-сюда - не продуктивно, а ещё лимиты эти… Решилась она попробовать рекомендованный мною RooCode с Gemini flash. Установила впервые IDE VSCode, запустила и поставила плагин RooCode, подключила Gemini модель и попыталась скормить ему ту же задачу, но в ответ получила какой-то откровенный бред. Вместе мы выяснили, что для адекватной работы RooCode (а ещё его предшественника Cline и, скорее всего, последователя Kilo Code) требуется не просто запустить VSCode, но ещё и создать в нём проект с соответствующей директорий где-то в системе. А если ещё и все материалы сложить в эту директорию - их можно не копипастить и даже не драгндропать, а меньшонить через @ что намного удобней. (Даже мне стало плохо от обилия англицизмов в этом предложении, извините). Кроме того, выяснилось, что промпт содержал помимо текста ещё ссылку на Figma дизайн. А RooCode, несмотря на то что может используя браузер, какую-то осмысленную деятельность с этой ссылкой вести. При наличии у него Figma MCP справляется гораздо эффективнее.
И теперь бесплатный Gemini flash под капотом RooCode засиял во всей красе. Промпты стали проще и читаемей. И благодаря доступу ко всем необходимым файлам (ВБТ и шаблон) и инструментам, RooCode ваншотом не просто создал качественное ТЗ в формате markdown (привет markdown preview плагин), но ещё и наполнил его нужными скриншотами прямо в теле документа, чего Claude не мог.
Вот только осталась одна проблема: он использовал скриншоты целых экранов, и не смог их порезать на кусочки для документирования соответствующих секций: шапка, меню т.п.
Фигня война! - сказал я, — наверняка есть MCP который это делает.
Погуглив вместе минут 15 мы обнаружили, что такого нет. Но так как нарезка экранов на скриншоты - привычная для системного аналитика задача, она поблагодарила меня за получившийся результат и убежала на другой звонок. А я остался сидеть глядя в пустой монитор с непониманием, почему такая простая и очевидная задача ещё не решена.
Так появилась идея ImageWizard - взять ImageMagic и прикрутить к нему MCP протокол.
А почему сейчас проект и называется иначе и никакой связи с ImageMagic не имеет, расскажу в следующей серии.
AI-синхронизация губ: от Wav2Lip до коммерческих решений
Технологии автоматической синхронизации движений губ с аудио перешли от исследовательских проектов к готовым продуктам. Современные сервисы создают реалистичное видео за секунды, где персонаж произносит любой текст с сохранением деталей лица.
Ключевые прорывы
Wav2Lip (2020, IIT Hyderabad) стал первой моделью, работающей без предварительного обучения на конкретном человеке. Исследование показало возможность генерации синхронизированного видео на основе GAN-архитектуры с дискриминатором, обученным отличать реальные движения губ от синтетических.
FaceFormer от Microsoft Research (2022) применил трансформерную архитектуру. Модель использует 6-слойный Transformer для обработки MFCC-признаков аудио и генерирует 768 3D-точек лицевых landmarks с учетом временных зависимостей.
Коммерческие решения
Lipsync 2.0 от Sync Labs работает как zero-shot модель без настройки. Поддерживает обработку видео с несколькими говорящими в кадре.
D-ID Creative Reality Studio генерирует говорящие аватары из статичных фото, ограничен 5-минутными роликами в базовой версии.
Synthesia ориентирована на корпоративный сегмент с готовыми AI-аватарами. Стоимость от $30/месяц за 10 минут видео.
Технические характеристики
Производительность:
CPU Intel i7: 1 секунда видео за 30-45 секунд обработки
GPU RTX 3060: соотношение 1:3
GPU RTX 4090: близко к real-time (1:1.2)
Метрики качества:
LSE-D (точность синхронизации): лучшие модели <8.0
SSIM (сохранение деталей): целевое значение >0.85
FID (реалистичность): оценка качества генерации
Практические применения
Стриминговые платформы: Netflix автоматизирует дубляж сериалов, сокращая локализацию с 3-6 месяцев до 2-3 недель.
Образование: Coursera тестирует многоязычные версии курсов с автоматической синхронизацией губ преподавателей.
Соцсети: TikTok экспериментирует с автопереводом популярных роликов, YouTube Creator Studio планирует функцию автодубляжа к 2026 году.
Ограничения
Качество исходного материала: требует четкого видео минимум 256×256px с углом поворота головы ±30° от фронтального.
Языковые особенности: модели обучены на английском. Для агглютинативных языков (финский, турецкий) точность падает на 15-20%.
Детекция артефактов: современные детекторы находят AI-генерацию с точностью до 95% (FakeSpotter — 94.2%, Microsoft Video Authenticator — 91.8%).
Представлен сервис Kira.art, который позволяет редактировать картинки прямо в чате. Все просто: грузим картинку и описываем, что хотим получить. Никаких кистей, слоёв и прочих инструментов. Можно поменять оттенок глаз на фото, добавить или удалить фон и другие предметы, создать арт или стилизовать пикчу, например, в аниме. Внутри также есть встроенный апскейлер — бустануть качество фото можно в несколько раз. Никаких сложных промптов, диалог идёт на естественном языке.
Как мы синхронизировали съемку для возрожденного проекта DPED
Команда регионального научно-образовательного центра «Искусственный интеллект и анализ больших данных» при НГТУ им. Р. Е. Алексеева продолжает рассказывать о работе по возрождению и улучшению DPED (Deep Photo Enhancement Dataset).
Мы решили задачи автоматизации, но столкнулись с еще одной проблемой: фото на планшете и камере снимались с некоторой задержкой относительно друг друга. Использование простых пауз (time.sleep) оказалось ненадежно и неэффективно. Тогда мы реализовали многопоточное решение:
Первый поток управляет съемкой с камеры с помощью библиотеки pyautogui.
Второй поток управляет съемкой с планшета через ADB.
Оба потока обмениваются информацией через очередь (queue.Queue() из стандартной библиотеки Python) — это потокобезопасная структура данных, которая позволяет одному потоку передать сигнал другому. В нашем случае очередь используется для передачи сигнала о начале съемки с камеры. Получив этот сигнал, планшет почти без задержки запускает захват изображения.
В процессе тестирования среднее время задержки составило 50 мс, но разброс данных достигал 93 мс. То есть, существуют случаи, когда мы получаем изображения с непозволительной задержкой в 100 мс и более. Мы отметили этот момент, но продолжили собирать датасет, а изображения с большой задержкой — удалять.
Скрипт автоматизации съемки кадров:
import subprocess
from threading import Thread
import pyautogui
import time
from queue import Queue
# координаты для кликов мыши
CAMERA_SHUTTER_BUTTON = (329, 748) # кнопка затвора в приложении
FOCUS_POINT = (1189, 204) # точка фокуса или область кадра
def tablet(q):
time.sleep(0.1)
if q.get() == 1:
p = subprocess.Popen(r'.\adb.exe shell', stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
p.stdin.write(b'input keyevent 27')
p.stdin.close()
def camera(q):
pyautogui.click(*CAMERA_SHUTTER_BUTTON)
pyautogui.moveTo(*FOCUS_POINT)
q.put(1)
pyautogui.mouseDown()
time.sleep(0.02)
pyautogui.mouseUp()
q = Queue()
thread1 = Thread(target=camera, args=(q,))
thread2 = Thread(target=tablet, args=(q,))
thread1.start()
thread2.start()
В оригинальной работе DPED точные значения задержки не указывались: авторы фиксировали устройства на механическом стенде и выполняли съемку вручную, без программной синхронизации или последующего анализа временного лага между кадрами. Насколько нам удалось выяснить, синхронизация производилась «на глаз», что не позволяет оценить точность в миллисекундах. Таким образом, можно утверждать, что наша реализация обеспечивает более детерминированный и измеримый результат по синхронизации.
Читайте в статье, как команда регионального научно-образовательного центра «Искусственный интеллект и анализ больших данных» при НГТУ доводит снимки с планшета YADRO KVADRA_T до качества полупрофессиональной камеры Sony Alpha ILCE 6600.
Apple выпустила рекламу своей ИИ‑опции Clean Up по стиранию с фото разных объектов. В ролике показано, как можно удалить кота с фото. Изменения можно отменить, что и пришлось сделать герою видео, который решил «стереть» кота со снимка с супругой.
Как улучшить режим ночной съемки с помощью нейросети на примере MEFNet
Смешивание экспозиций обычно применяют для улучшения изображений при дневной съемке, особенно в условиях яркого солнца. Но мы решили проверить: можно ли адаптировать этот способ для съемки в темноте? Он поможет осветлить изображение и заметно снизить уровень шумов.
MEFNet — это подход к слиянию изображений с разной экспозицией. Он создан для работы со статическими последовательностями кадров произвольного разрешения и в произвольном количестве. Название MEFNet происходит от термина Multi-Exposure Fusion, то есть «многоэкспозиционное смешивание». Отсюда и сокращение MEF.
Главная цель MEFNet — извлекать полезные детали как из темных, так и из пересвеченных областей, чтобы сформировать итоговое изображение с хорошим балансом яркости и контраста. При этом метод должен избегать артефактов, характерных для классических алгоритмов.
Схема работы алгоритма MEFNet. Источник: Ma, K., Duanmu, Z., Zhu, H., Fang, Y., & Wang, Z. (2019). Deep guided learning for fast multi-exposure image fusion. IEEE Transactions on Image Processing, 29, 2808-2819
Схема работы алгоритма MEFNet. Источник: Ma, K., Duanmu, Z., Zhu, H., Fang, Y., & Wang, Z. (2019). Deep guided learning for fast multi-exposure image fusion. IEEE Transactions on Image Processing, 29, 2808-2819
Алгоритм MEFNet работает следующим образом. На вход подается серия изображений с разной экспозицией — они сначала переводятся в YUV-формат. Далее основная обработка выполняется только по Y-каналу, который отвечает за яркость. Дело в том, что именно яркостный компонент в наибольшей степени определяет структуру и детализацию сцены.
Затем нужно уменьшить разрешение всех изображений — так сокращаются вычислительные затраты. Полученные кадры поступают в нейросеть, которая генерирует весовые карты для каждого изображения, также в пониженном разрешении. Она обрабатывает серии произвольного пространственного размера и числа экспозиций, а также генерирует карты соответствующего размера и количества. Сеть состоит из семи сверточных слоев с расширенными свертками, которые увеличивают поле восприятия (receptive field) без потери разрешения:
Слои 1–6 используют ядра размером 3×3 с разными коэффициентами расширения (dilation rates): 1, 2, 4, 8, 16, 1. Это позволяет захватывать контекст на разных масштабах.
Слой 7 — финальный слой с ядром 1×1, который преобразует фичи в весовые карты.
Нормализация — после каждого сверточного слоя (кроме последнего) применяется адаптивная нормализация (AN), сочетающая нормализацию по экземпляру (instance normalization) с обучаемыми параметрами.
Активация — используется Leaky ReLU (LReLU) для сохранения структурной информации.
Подробнее о MEFNet и других алгоритмах улучшения режима ночной съемки в мобильных устройствах на примере планшета KVADRA_T читайте в статье Полины Лукичевой из команды AI ML Kit в YADRO.
В системах видеонаблюдения и видеоаналитики часто приходится иметь дело с кадрами низкого качества. Объект съемки далеко, плохое освещение, ограниченные возможности камеры – и вместо четкой картинки мы получаем лишь набор пикселей. Знакомая ситуация?
"Что тут происходит? 😑"
Почему это большая проблема?
Распознать что-либо по такому "размытому квадратику" – серьезный вызов для алгоритмов. Стандартные модели, обученные на четких изображениях, часто теряют эффективность, когда объект занимает по высоте всего 32 пикселя (а то и 10!). Это напрямую влияет на точность работы систем в реальных условиях – будь то поиск автомобиля, предмета или распознавание лиц.
В чем сложность?
Главная трудность – "пропасть" между миром четких картинок (на которых обычно учатся модели) и миром размытых кадров. Алгоритмы плохо переносят знания из одного "мира" в другой.
Как с этим бороться?
В нашей новой (и первой) статье мы подробно разобрали ключевые подходы к решению такой проблемы в контексте распознавания лиц:
1. "Дорисовка" деталей: специальные нейросети пытаются увеличить и улучшить размытое изображение перед анализом. Работает, но есть риск "придумать" несуществующие детали.
2. Адаптация модели: как "подружить" алгоритм с плохим качеством?
Трюки с данными: искусственно ухудшаем хорошие изображения при обучении (сжатие, шум), чтобы модель привыкла к помехам.
Дообучение: учим модель на реальных размытых данных. Важно делать это аккуратно, чтобы она не забыла, как работать с четкими изображениями. Помогают методы вроде LoRA (дообучение только маленькой части сети).
"Учитель" для "ученика": мощная модель, видящая четкие картинки, учит компактную модель работать с размытыми, передавая свои "знания".
3. PETALface: новый подход, который динамически комбинирует разные "настройки" (LoRA-адаптеры) в модели в зависимости от качества конкретного входящего кадра. Перспективно, но требует дальнейшего изучения.
Хотите разобраться глубже?
В статье мы подробно разбираем плюсы и минусы каждого подхода, рассматриваем специализированные датасеты (TinyFace, BRIAR) и анализируем нюансы свежего метода PETALface.
Сталкивались ли вы с проблемой низкого разрешения в своих проектах? Какие методы оказались эффективными? Делитесь опытом в комментариях!
Осваиваем азы компьютерного зрения с библиотекой Pillow на одноплатном компьютере Lichee Pi 4A
Наш первый шаг — загрузить изображение, определить его цветовую модель и получить информацию о размере и границах.
from PIL import Image
from PIL import ImageFilter
img = Image.open(“flower.jpg”)
print(img.size, img.format, img.mode)
Эта базовая информация пригодится для дальнейшей работы с изображением.
Меняем цвет пикселя
К отдельным пикселям можно обращаться с помощью метода load() из библиотеки Pillow. Так мы сможем изменять цветовые значения точечно, а это основа для различных операций по обработке изображений.
Открываем white.jpg с помощью Pillow:
from PIL import Image
img = Image.open("white.jpg")
obj = img.load()
Выбираем пиксель с координатами (25, 45) и меняем его цвет:
Метод load() позволяет напрямую работать с массивом пикселей изображения: читать, модифицировать и анализировать отдельные элементы, не копируя данные в отдельные структуры. Это особенно важно для задач, которые требуют высокую производительность при обработке больших изображений.
Почему был выбран Lichee Pi 4A, как создать виртуальное окружение Python, установить подходящую среду разработки и научиться базовым приемам работы с изображениями — читайте в подробном туториале.
Представлен сервис для удаления фона с необычным дизайном — ваша фотка буквально отправляется в стирку. Работает просто: закидываете картинку в машину, пару секунд наблюдаете за гипнотизирующим барабаном и забираете PNG-шку. Дизайнеры познают дзен — здесь.
Представлен проект сканирования в разрешении 108B (108 Gigapixel) одной из наиболее известных картин нидерландского художника Яна Вермеера — «Девушка с жемчужной серёжкой» (нидерл. Het meisje met de parel). На скане картины можо рассмотреть каждый небольшой мазок и саму мелкую трещинку.
Как автоматизировать распознавание текста с изображений?
В открытых источниках часто встречаются изображения с ценным текстом — скриншоты рабочих столов и приложений, фотографии таблиц, чеков, рукописных заметок и т.д. Сбор обычного текста автоматизировать легко, но с текстом на картинках начинаются сложности.
Раньше в моём арсенале был только pytesseract (Python-библиотека для распознавания текста). Она работала, но с серьёзными ограничениями: ➖Плохо справлялась с разными шрифтами ➖Теряла точность на низкокачественных изображениях ➖Путала языки, если текст был мультиязычным
Сейчас появились LLM-модели, которые справляются с этой задачей гораздо лучше, но если у вас нет мощного железа, запустить их локально не получится.
В профильных каналах регулярно пишут: «Вышла модель Х, которая показывает отличные результаты. OSINT-еры больше не нужны!», но никто не дает гайдов, как с этими моделями работать. Сегодня я это исправлю.
Обзор моделей для OCR Прошерстив не один десяток источников, я выделил две наиболее популярные на текущий момент модели: 1️⃣ GPT-4 mini — высокая точность, но платная. 2️⃣ Google Gemini 2.0 Flash — высокая точность + бесплатный лимит.
Выбор без раздумий пал на Gemini. На момент публикации бесплатные лимиты от Google следующие: ✔️ 15 запросов в минуту ✔️ 1 млн токенов в минуту (ввод + вывод) ✔️ 1 500 запросов в сутки
Как взаимодействовать с Gemini? 1️⃣ Получаем API-ключ в Google AI Studio 2️⃣ Через API отправляем изображение в base64 + промпт 3️⃣ Получаем распознанный текст в ответе
Но есть важный нюанс: сервис не работает с российскими IP
Что делать, если Gemini недоступна? Если у вас по какой-то причине нет возможности получить доступ к серверам Google AI Studio, то можно воспользоваться сервисами, которые предоставляют доступ к различным open-source моделям. Например, DeepInfra. Плюсы: ✔️ Нет блокировок по геолокации ✔️ Гибкая тарификация Минусы: ✖️ Нет бесплатного тарифа
Верните мой 2007-й: превращаем старые фотки в снимки с зеркалок с помощью ИИ
Однажды группе ИИ-энтузиастов пришла идея: а что если обучить искусственный интеллект улучшать смартфонные снимки до профессиональных с помощью парных фотографий? Задумка понравилась. Для сбора датасета выбрали актуальные в то время Sony Xperia Z, iPhone 3GS, BlackBerry Passport и цифровую зеркалку Canon EOS 70D в качестве эталона. Модель обучили улучшать фотографии, сделанные на смартфонах, в соответствии с такими же изображениями, полученными с камеры. Проект реализовали, исходный код опубликовали на GitHub, а подробное описание — на arXiv.org. Но что же в нем интересного сейчас, почти десять лет спустя?
DPED не просто применяет косметические фильтры. Датасет способен значительно улучшать фотографии на уровне структуры изображения, детализации, динамического диапазона и цветопередачи, приближая результат именно к профессиональной зеркальной фотокамере, а не просто «улучшая» фото.
Открытый исходный код и доступность датасета DPED позволяют легко адаптировать, изменять и дорабатывать модель. Это дает большие возможности исследовательскому сообществу и разработчикам мобильных приложений. Именно гибкость и понятность архитектуры делают DPED хорошим кандидатом для дальнейших экспериментов и улучшений.
В своей статье команда регионального научно-образовательного центра «Искусственный интеллект и анализ больших данных» при НГТУ им. Р. Е. Алексеева запустила DPED на свежих версиях софта, преодолев все проблемы совместимости, и попробовала через него улучшить фото с современного планшета.
Итак, пятница уже не первый час шагает по глобусу, поэтому держите свеженький выстрел в мозги ;)
Недавнее обсуждение «тыкательного принтера», естественно, не может не будить в пытливых умах вопрос, как бы повысить его скорость печати? Не избежал этой участи и я. Физически всё просто — надо поменьше отрывать тяжёлую ручку от бумаги и рисовать как можно более длинными штрихами. Но как разбить произвольное изображение на штрихи?
Разумеется, решение для искусственно самоограниченной задачи, когда ручка движется строго по горизонтали и бумага после каждого прохода подаётся на один диаметр шарика ручки — элементарное. Берём RLE и Флойда-Стейнберга, за 15 минут пишем этот код:
#define SQUARE(x) ((x)*(x))
#define MAXERROR 256 //for RLE
static unsigned char Grayscale8Bit[HEIGHT][WIDTH], Dithered8Bit[HEIGHT][WIDTH];
static signed short AdditionalError[2][WIDTH];
тут мы читаем из файла Grayscale8Bit, этот код я приводить не буду
memset (AdditionalError, 0, 2*WIDTH*sizeof(short)); //Even/odd lines buffer
for (int y=0; y<HEIGHT; y++)
{
int RLEError=0;
int PenColor = 255*(Grayscale8Bit[y][0]>127); //Pen color can be either 0 or 255
for (int x=0; x<WIDTH; x++)
{
int PixelValue = (int)Grayscale8Bit[y][x] + AdditionalError[y&1][x]; //Exact pixel value plus Floyd-Steinberg error from the prev. line
RLEError += SQUARE (PixelValue - PenColor); //To avoid missing contrast details such as thin vertical lines, RLE error counted as square.
if (RLEError > SQUARE (MAXERROR))
{
PenColor = 255-PenColor; //Inverse pen position (up/down)
RLEError = SQUARE (PixelValue - PenColor); //Begin counting new RLE error immediately
}
Dithered8Bit[y][x]=PenColor; //Put proper color into the output array
AdditionalError[!(y&1)][x] = (PixelValue - PenColor)/2; //Put remaining error into next line buffer, not exactly Floyd-Steinberg but sort of.
if (x) AdditionalError[!(y&1)][x-1] = (PixelValue - PenColor)/4;
if (x<WIDTH-1) AdditionalError[!(y&1)][x+1] = (PixelValue - PenColor)/4;
}
}
тут мы пишем в файл Dithered8Bit, этот код тоже у каждого свой получится
Код без каких-либо капризов, отладки и подбора параметров сразу выдаёт результат:
Сверху, как нетрудно догадаться, оригинал.
Ну то есть задача в её куцем виде — совсем детская. Там не то что думать не пришлось, даже ошибиться негде было. Но и результат тоже, мягко говоря, так себе.
Ну а теперь вот вам по случаю пятницы головоломка: как полностью реализовать потенциал не одной, а двух степеней свободы нашего привода, да ещё с учётом того, что скорость протяжки бумаги и скорость вошканья каретки в общем случае друг другу не равны, а проходить ручкой по одному месту больше одного-двух раз — нежелательно, бумага не чугунная. Мучайтесь и ломайте головы над возможными алгоритмами такого вот обхода растра ;)
Спойлер, но вы его сразу не читайте, чтобы не сбиться со своих мыслей: я бы, наверное, обошёл сначала изолинии крупных элементов, разбивая пространство между ними на более или менее густые штриховки, а потом уже прикинул бы ошибку и добавил-убавил штрихи сообразно мелким деталям. Перо, идущее вдоль изолиний — в общем случае довольно хорошая идея, когда надо не убить разборчивость изображения, а то даже ещё и усилить её. Но, правда, это касается только фотореалистичных изображений, а в задаче-то у нас произвольные.
Сервис ITOA: Image to ASCII Converterпревращает любое изображение в ASCII-картинку — в цвете или монохроме. Результат можно сохранить в символах или в PNG.
Трудно найти в темной комнате документ, особенно если его там нет
Представим, что нам нужно сделать нормальное фото документа, но положить листик как в сканере — более-менее ровно, в фокусе, под достаточным и равномерным светом — мы не можем. Поможет ли здесь ИИ? Конечно, если мы научим его решать некоторые вопросы, например:
Есть ли вообще документ на фото?
А это лист А4 или микроволновка?
Если есть, где его границы?
Если границы кривые, как их выпрямить?
А это документ или тень от документа?
Команда YADRO прошла этот квест, начав с простых CV-алгоритмов. По пути собрали свою нейросеть, а также инструмент для создания подходящих датасетов на основе модификации ControlNet для Stable Diffusion. В результате планшет Kvadra_T научился определять документы в реальном времени — прямо в приложении камеры.
Все подробности развития проекта, включая схемы реализации и подробные параметры обучения, — в статье Владислава, CV Engineer YADRO.
