Лето, скоро отпуск — захотелось написать статью, которую просто кайф прочитать, и заодно попробовать что‑то новое. Для ИИ есть бенчмарки вроде HumanEval, где модель просят написать функцию на пару строк, есть задачи уровня «сделай мне todo‑лист на React». А что будет, если дать современным ИИ‑агентам по‑настоящему наукоёмкую задачу — реализовать алгоритм из статьи SIGGRAPH на Swift, без сторонних библиотек, — и потом честно сравнить, что получилось на выходе?
Для этого я взял алгоритм «Depixelizing Pixel Art» (Johannes Kopf, Dani Lischinski, SIGGRAPH 2011) — тот, который я когда‑то давно реализовывал на C++. Поставил одинаковую задачу реализовать на языке Swift разным агентам (Claude, Codex, Cursor, Cline, Antigravity, Kimi, Grok — на разных моделях). Условия просты — один промпт = одна реализация, без уточнений, указаний недочетов и итераций правок
Вот полный текст промпта:
Скрытый текст
## Задание Ты выполняешь готовый план реализации алгоритма **«Depixelizing Pixel Art»** (J. Kopf, D. Lischinski, SIGGRAPH 2011). Статья лежит рядом: `pixel.pdf`. Следуй плану шаг за шагом, не пропускай шаги и не заменяй алгоритм другим. Если шаг невозможно выполнить точно — реализуй указанное в нём упрощение и зафиксируй отклонение в `solution/NOTES.md`. ### Шаг 0. Контракт - Прочитай `config.txt`: `language` — язык реализации, `os` — целевая ОС (для кроссплатформенного языка игнорируется), `upscale` — целочисленный множитель увеличения. - Весь код помести в папку `solution/`. - Обработай **каждый** файл из `input/`. Результат сохрани в `output/`, заменив в имени суффикс `_input` на `_output` (`smw_boo_input.png` → `smw_boo_output.png`), формат PNG. - Размер каждого результата: `(W*upscale) x (H*upscale)`, где `W x H` — размер оригинала. - Запуск — одной командой; команду опиши в `solution/README.md`. ### Шаг 1. Подготовка проекта - Модули: конфиг, ввод/вывод изображений, граф похожести, эвристики, перестройка ячеек, сплайны, оптимизация, рендеринг, точка входа. - Зависимости — только базовые: чтение/запись PNG и математика. **Запрещены** готовые реализации апскейла/векторизации (hqx, xBR, Scale2x/ScaleNx, EPX, 2xSaI, potrace, функции масштабирования из opencv/PIL как итоговый результат). - Загрузка изображения в RGB. Если есть альфа-канал: полностью прозрачные пиксели считай отдельным самостоятельным «цветом». ### Шаг 2. Граф похожести (статья, §3.2, начало) - Узел на каждый пиксель, рёбра ко всем 8 соседям (включая диагонали). - Переведи цвета в YUV. Ребро удаляется, если цвета «непохожи»: `|dY| > 48/255` **или** `|dU| > 7/255` **или** `|dV| > 6/255`. - Самопроверка: на однотонной картинке граф остаётся полным; на шахматной доске 1x1 остаются только диагональные рёбра внутри каждого цвета. ### Шаг 3. Разрешение пересекающихся диагоналей (§3.2) Для каждого блока 2x2, в котором присутствуют обе диагонали: - Если блок полностью связан (все четыре пикселя взаимно похожи) — удали обе диагонали: это плоско закрашенная область. - Иначе подсчитай голоса трёх эвристик за каждую из диагоналей: - **Кривые.** Если диагональ — часть цепочки узлов валентности 2, она принадлежит «кривой». Вычисли длины двух кривых, проходящих через две диагонали; голос за более длинную, вес = разность длин. - **Разреженные пиксели.** В окне 8x8 с центром в блоке сравни размеры компонент связности, к которым подключены концы каждой диагонали. Голос за диагональ компоненты **меньшего** размера (разреженный цвет — передний план), вес = разность размеров компонент. - **Острова.** Если у одного из концов диагонали валентность 1, её удаление создаст одинокий пиксель-«остров». Голос за сохранение этой диагонали с фиксированным весом **5**. - Оставь диагональ с большей суммой весов; при равенстве удали обе. - Результат: планарный граф. - Самопроверка: визуализируй граф для `smw_boo_input.png` и сравни со схемой Figure 3(c) статьи. ### Шаг 4. Перестройка пиксельных ячеек (§3.2, конец) - Построй **упрощённую обобщённую диаграмму Вороного**: проход окном 3x3 по графу, подстановка готовых шаблонов формы ячеек (формы перечислимы, потому что граф планарен). - Координаты узлов ячеек квантованы к **четвертям пикселя**. - Схлопни узлы валентности 2 для упрощения диаграммы. - Самопроверка: похожие пиксели, соседние по диагонали, теперь делят общее ребро ячейки; сравни с Figure 3(d). ### Шаг 5. Извлечение сплайнов (§3.3) - Ребро ячейки **видимое**, если цвета по его сторонам различны (критерий из шага 2). - Последовательности видимых рёбер, проходящие через узлы валентности 2 (по видимым рёбрам), преврати в **квадратичные B-сплайны**; контрольные точки — узлы ячеек. - T-стыки (три видимых ребра в одном узле): классифицируй каждое ребро как «теневое» (shading), если YUV-расстояние цветов с двух сторон `<= 100/255`, иначе «контурное». Если теневое ровно одно — соедини два контурных в один сплайн. Иначе соедини пару рёбер с углом, ближайшим к 180 градусам. Конец третьей кривой спроецируй на продолжающуюся кривую (B-сплайн не интерполирует контрольные точки). - Самопроверка: отрисуй сплайны поверх сетки, сравни с Figure 3(e). ### Шаг 6. Оптимизация кривых (§3.4) - Минимизируй сумму поузловых энергий `E = Es + Ep`: - `Es` — гладкость: интеграл `|kappa| ds` (модуль кривизны) по участку кривой, на который влияет узел; считай численно, сэмплированием с фиксированным шагом. - `Ep` — позиция: `||p - p_hat||^4`, где `p_hat` — исходное положение узла (четвёртая степень: свободно в малом радиусе, резкий штраф дальше). - Релаксация: случайный обход узлов; для каждого пробуй несколько случайных смещений в малом радиусе, оставляй лучшее. Несколько итераций. **Зафиксируй seed** — результат должен быть воспроизводим. - Углы: найди в перестроенном графе ячеек шаблоны углов (Figure 7, плюс их повороты и отражения) и исключи участки кривой между узлами шаблона из интеграла гладкости — намеренно острые углы сглаживать нельзя. - Допустимое упрощение: вместо гармонических отображений для узлов, не лежащих на сплайнах, — локальное усреднение соседей или пропуск перепозиционирования (выбор зафиксируй в NOTES.md). - Самопроверка: «лесенка» на длинных дугах исчезает, сравни с Figure 6(b)→(c). ### Шаг 7. Рендеринг (§3.5) - Растеризуй результат в `(W*upscale) x (H*upscale)`. - Эталонный способ: цвет точки — взвешенное среднее цветов ячеек с усечёнными гауссовыми влияниями (`sigma = 1`, радиус 2 ячейки), размещёнными в центроидах ячеек; влияние **не распространяется через контурные сплайны** (edge-aware). - Допустимое упрощение: залить каждую область, ограниченную сплайнами, цветом её ячеек, с антиалиасингом по границам (суперсэмплинг не менее 4x). - **Запрещено**: nearest neighbor / bilinear / bicubic как итоговый способ масштабирования. ### Шаг 8. Прогон и самопроверка - Прогони все файлы из `input/`. - Проверь: все выходные файлы существуют, размеры верны, повторный запуск даёт идентичный результат. - Сравни выходы с эталонами в статье: `smw_dolphin` — Figure 1, `smw_boo` — Figure 3(f), `invaders_03` — Figure 9, `sma_toad` — Figure 9, `win31_keyboard` — Figure 9, `smw2_yoshi_*` — Figure 9 (Yoshi). - Все отклонения от плана зафиксируй в `solution/NOTES.md`. ### Критерии готовности - [ ] В `output/` лежит результат для каждого входного файла, размеры `(W,H) * upscale`. - [ ] Контуры гладкие, без «лесенки»; тонкие линии не разорваны; одиночные пиксели (глаза персонажей) не потеряны. - [ ] Язык реализации соответствует `config.txt`; запуск одной командой по `solution/README.md`. - [ ] Повторный запуск даёт байт-в-байт тот же результат.
Оценивать результаты я «пригласил» тоже три разных ИИ — Claude, Codex и Antigravity (Gemini).
Что за задача и почему она сложная
«Depixelizing Pixel Art» — это алгоритм, который восстанавливает намерение художника: где у спрайта непрерывный контур, где тонкая диагональная линия в один пиксель, а где одиночная точка-блик, которую нельзя терять.
Оценка на верность производилась по этим пяти этапам:
Граф похожести. 8-связность, сравнение пикселей в пространстве YUV с порогами из статьи (48/255 по яркости, 7/255 и 6/255 по цветности).
Разрешение диагоналей. В полносвязном блоке 2×2 надо выбрать одну из двух диагоналей по трём эвристикам (продолжение кривых, разреженные пиксели с окном 8×8, «острова» с весом 5); ничья — удалить обе.
Перестройка ячеек. Упрощённая обобщённая диаграмма Вороного, узлы квантуются к четвертям пикселя.
Сплайны. Видимые рёбра превращаются в квадратичные B-сплайны; отдельно обрабатываются T-стыки (теневые/контурные рёбра, порог 100/255, угол ближе к 180°).
Оптимизация кривых. Минимизация энергии «гладкость + позиция», при этом узловые шаблоны углов из сглаживания исключаются (углы должны остаться углами).
Вот как выглядит вход — 18×18 пикселей, на которые без увеличения и не взглянешь:
А вот эталон, к которому все стремились, — Figure 3(f) из статьи: гладкий контур, два глаза (правый — характерный «крючок»), намеренно «волнистый» розовый рот и мягкая тень.
А судьи кто? Главный тест всего бенчмарка
Оценка шла по 100-балльной шкале, пять категорий: контракт (25), верность алгоритму (30), визуальное качество (20), инженерное качество (15), процесс (10).
Но самое полезное в проверке оказалось почти тривиальным. Это тест на даунсэмплинг:
Взять выход 288×288, усреднить его обратно до 18×18 методом BOX, сравнить с оригиналом. Если средняя дельта около нуля — значит каждый блок 16×16 в выходе постоянен и выход практически полностью состоит из однородных блоков. А это и есть обычный nearest-neighbour, то есть депикселизации не было вообще.
import numpy as np from PIL import Image up = 16 src = Image.open("input/smw_boo_input.png").convert("RGB") out = Image.open("output/smw_boo_output.png").convert("RGB") ds = out.resize(src.size, Image.BOX) # свернуть выход обратно к 18×18 d = np.abs(np.float32(src) - np.float32(ds)).mean() print(f"средняя дельта: {d:.1f}") # 10–25 — норма; 0.0 — это resize
Десять строк Python — и стало видно то, что не видно при беглом просмотре «красивых» исходников. Нормальное сглаживание «съедает» углы и даёт дельту в районе 10–25. Ноль означает, что модель просто растянула картинку.
Модель / агент | Размер | Δ к входу | Пикселей ≠ NN | Что это значит |
|---|---|---|---|---|
Claude Fable 5 | 288² | 24.2 | 39.98% | норма, есть сглаживание |
Codex 5.5 | 288² | 40.2 → 21.3 при v-flip | 47.17% | обработка есть, но кадр перевёрнут |
Cursor Auto | 288² | 27.8 | 25.77% | обработка есть, но рендер битый |
Kimi Code 2.7 | 288² | 42.7 | 31.24% | обработка есть (рендер по Вороному) сплайны в рендере не участвуют |
Claude Sonnet 4.6 | 288² | 19.0 | 13.55% | норма, есть сглаживание |
Antigravity (Gemini 3.5 Flash) | 288² | 0.0 | 0.00% | чистый nearest ×16 |
Cline + DeepSeek v4 Pro | 288² | 0.0 | 0.00% | чистый nearest ×16 |
Cline + Qwen 3.7 Max | 288² | 0.0 | 0.00% | nearest ×16 |
Grok | 4608² | 0.0 | 1.85% | nearest ×256 — и неверный размер |
Все агенты Интересные особенности и впечатления:
Fable — идеальный результат (его разберем далее)
Codex честно выполнил все инструкции и получил перевернутое изображение (помню, когда я реализовывал этот алгоритм, также перевернутое изображение)
Kimi Code 2.7 высадил 5-часовой лимит за один промпт, застрял в петле из постоянных улучшений
Antigravity — отправился гуглить реализацию на питоне, открыл браузер и начал серфить
DeepSeek v4 Pro — прогон стоил всего $0,08 на токены
Общий зачёт (Оценка ИИ)
Ниже — сводка. Поскольку оценивали три разных ИИ-судьи (Claude, Codex, Antigravity/Gemini), я привожу баллы каждого: расхождения сами по себе любопытны (об этом — в разделе про судей).
Модель / агент | Claude | Codex | Gemini | Вердикт | |
|---|---|---|---|---|---|
🥇 | Claude Fable 5 | 97 | 97 | 100 | Отлично |
🥈 | Sonnet 4.6 | 81 | 85 | 88 | Хорошо |
🥉 | Codex 5.5 | 85 | 83 | 84 | Хорошо (кадр перевёрнут) |
4 | Kimi Code 2.7 | 76 | 78 | 80 | Хорошо — зачтено (рендер по Вороному) |
5 | Cursor Auto | 68 | 66 | 81.5 | Удовлетворительно |
— | Antigravity (Gemini 3.5 Flash) | - | 44 | 47 | Не зачтено (nearest) |
— | Cline + DeepSeek v4 Pro | - | 53 | 47 | Не зачтено (nearest) |
— | Cline + Qwen 3.7 Max | - | 40 | 42 | Не зачтено (nearest) |
— | Grok | - | 38 | 19 | Не зачтено (nearest ×256) |
А вот как это выглядит глазами — та самая картинка, ради которой стоит читать статью. Восемь результатов одного и того же призрака Boo:
Разница видна невооружённым глазом
Мой разбор призёров
Claude Fable — Однозначный лидер
Единственная реализация, которая одновременно и хорошо выглядит, и почти буквально покрывает все пять этапов алгоритма. Корректные YUV-пороги, все три эвристики диагоналей, четверть-пиксельные ячейки, квадратичные B-сплайны, полная логика T-стыков, шаблоны углов из Figure 7
Отдельно порадовала инженерия: фиксированный seed (SplitMix64), собственный PNG-кодер ради байт-в-байт воспроизводимости (два запуска → идентичный SHA-256), многопоточный рендер и режим --debug, выгружающий промежуточные этапы. Эти выгрузки можно прямо сопоставить со статьёй:
2. Перестроенные ячейки Вороного, узлы квантованы к ¼ пикселя (Figure 3d).
3. Сплайны на видимых рёбрах (Figure 3e): «лесенка» становится кривыми.
4. Финальный рендер — практически эталон.
Codex — моё второе место
По исходникам это одна из самых полных реализаций: B1–B5 разнесены по модулям, есть self-test графа, T-стыки с проекцией по 32 точкам сплайна, защита тонких компонент, гауссов рендер и три диагностических картинки.
финальный PNG перевёрнут по вертикали (рассогласование «начала отсчёта Y» между чтением и записью буфера) — поэтому все «ИИ-судьи» снизили баллы
Claude Sonnet
Результат: контур получился заметно гранёным — сплайны не убрали «лесенку», а превратили её в многоугольные фасетки; глаза стали ромбовидными, рот потерял волну. Плюс из-за ошибок округления на границах полигонов появились микро-зазоры (полупрозрачные пиксели). Цветовая верность при этом хорошая.
Kimi Code 2.7 —маньяк перфекционист
Мой приз зрительских симпатий, модель действительно старалась, когда я увидел, что потрачено 20% 5-часового лимита — я улыбнулся, 50% — я уже ждал "ошеломляющий" результат, и дальше с упоением наблюдал как заполняется 100%
Результат оказался далёк от идеала, но именно Kimi показал самое интересное агентное поведение: вместо решения задачи он начал бесконечно улучшать собственное решение и в итоге сжёг весь доступный лимит.
Выводы
Claude Fable — чистый победитель. Единственный результат уровня эталона статьи, ещё и с диагностикой этапов и байт-в-байт воспроизводимостью. Пример когда модель понимает задачу, а не имитирует понимание
Главный вывод: для AI-агентов нужен численный критерий. Это вероятностные системы, и статическое ревью «красивого кода» не показывает, работает ли алгоритм на самом деле.
Много кода — не всегда работающий результат. Antigravity и Cline+DeepSeek написали полноценный каркас алгоритма с графами и сплайнами — и из-за одной логической ошибки (схлопывание коллинеарных вершин) всё выродилось в просто ресайз. Сквозные smoke-тесты на синтетике обязательны прямо в цикле генерации.
LLM-судьи воспроизводимы ровно настолько, насколько объективны критерии. По числам — консенсус, по «вкусу» — разброс в 15 баллов. Это работающий рецепт для любого, кто строит автоматическую оценку на LLM.
Если кто-то захочет прогнать этот же тест на Kotlin, Rust, C#, Zig или любом другом языке — вот репозиторий с полным промптом, исходными артефактами и структурой, которую я использовал для эксперимента.
