Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 4
Спасибо. Интересное чтиво.
Верно подметили, у нас тоже
precision: 0.99решает все проблемы в 99%.
У нас в тестах (гоняем через fastlane) захардкожен Xcode версия и симулятор версия для snapshot тестов, поэтому проблемы только при миграции на новые симуляторы, вот недавно переехали кажется с 18.2 iOS на 18.6 iOS или с Xcode 16.2 на 16.4 уже не помню, поехали все иероглифы (корейский, бенгази языки) так как изменился шрифт для этих языков, пришлось всё перегенеривать для них.
А так проблем нет, бывает 1 раз в год, что тест сгенеренный на локальной машине не проходит на СИ (разница в несколько пикселей) тогда у нас СИ просто непрошедшие снапшоты заворачивает в zip архив и разработчик просто его скачивает и заменяет у себя локально так как source of truth у нас является СИ.
Прикольная статья, но остались некоторые вопросы.
1) Получается некая путаница с ΔE₇₆ и евклидовым расстоянием, то, что формулы идентичны - верно подмечено, но не объясняет главное: формула одинаковая, но применяется к разным пространствам (RGB vs CIELAB). Именно преобразование в CIELAB даёт перцептуальную равномерность, а не сама евклидова формула.
2) Некорректное утверждение о ΔE₉₄, в статье утверждается, что ΔE₉₄ считает чёрный и зелёный "абсолютно одинаковыми" - это технически неверно. ΔE₉₄ даст высокое значение для этой пары. Проблема ΔE₉₄ в другом: неравномерность в нейтральных оттенках и синей зоне.
3) Отсутствие упоминания white point - при конвертации RGB -> CIELAB критически важен выбор белой точки (D50, D65). Разные симуляторы/устройства могут использовать разные профили, что само по себе создаёт расхождения. Об этом ни слова.
4) Атомарный счётчик на GPU - потенциальное узкое место. atomic_fetch_add_explicit при большом количестве несовпадений создаёт некий contention. Для наивной стратегии с градиентами (454k несовпадений) это может деградировать производительность. Стоило упомянуть, почему это не проблема или как решается.
5) Кластерный анализ на GPU - алгоритм не раскрыт. Самая интересная часть - кластерная фильтрация - описана только концептуально. Как именно определяются "соседние" пиксели? Connected components на GPU - нетривиальная задача. Используется ли union-поиск? Какой радиус соседства?
6) Непонятно, что именно вызывает выбросы: CPU, iOS или Xcode?
7) Утверждение "230% прирост производительности" вызывает вопросы. Сравнивается своя Metal-реализация ΔE₂₀₀₀ с CILabDeltaE, который реализует ΔE₉₄ - это разные алгоритмы с разной вычислительной сложностью. Корректнее было бы сравнивать либо ΔE₂₀₀₀ на Metal vs ΔE₂₀₀₀ на CPU, либо показать полный пайплайн (включая накладные расходы CoreImage). Также напрягает отсутствие бенчмарков, методологии измерения и информации о размерах тестовых изображений.
1) Верно подмечено
2) Прекрасно, что существуют более осведомлённые в теме люди
4) "Атомарный счётчик на GPU - потенциальное узкое место." - Атомарное изменение действительно может поднимать вопросы производительности. Особенно в контексте скриншот тестирования с гигантскими расхождениями.
Ощутимая просадка производительности на моих наблюдениях не наблюдалась (наивная, Delta, комбинированная), atomic_fetch_add_explicit на удивление ведёт себя очень надежно и быстро. Но просадка для гигантских расхождений всё же есть - она появляется для стратегий с большим участием кластерной фильтрации и слабо связано с atomic_fetch_add_explicit. Для чисто кластерной стратегии в больших расхождениях время прохождения может увеличиться (c 0.04 секунд до 5 секунд) это в 125 раз больше.
Это не совсем приятно, но, учитывая, что тесты в основном прогоняются успешно или имеют расхождения на уровне шума, просадка остаётся относительно редкой и остаётся приемлемой (5 секунд, а не 5 минут). Бюджет проекта в 0 рублей пока не позволяет вносить дорогостоящие оптимизации без явного запроса от комьюнити.
И отвечая на вопрос «Стоило упомянуть, почему это не проблема или как решается» — по моим наблюдениям, явных проблем с массовым увеличением atomic_fetch_add_explicit замечено не было (хотя на этапах разработки я потенциально ожидал ощутимой просадки, т.к. понимаю сложность атомарных операций).
Ну и не стоит забывать, что инструмент стремится минимизировать количество атомарных операций через применение разных стратегий, а сами тесты вызывают гигантские расхождения относительно редко. Как полноценная проблема «атомарное увеличение» пока, на мой взгляд, особо и не сформировалась.
Если будут примеры проблемы / или предложения улучшения с радостью жду issue
5) "Кластерный анализ на GPU - алгоритм не раскрыт. Самая интересная часть ... Connected components на GPU - нетривиальная задача " - Мне казалось, что людям часть с кластерной стратегией будет наименее интересной :) Теперь же появляются мысли раскрыть кластерную / комбинированную стратегию в отдельной статье.
Кластерный стратегия - непаханое поле потенциальных улучшений и оптимизаций. Передо мной стояла задача создать приемлемо рабочий прототип и покрыть его тестами. В дальнейшем применять его в основном в комбинированном виде.
1) " Как именно определяются "соседние" пиксели? " - Саму реализацию лучше смотреть в исходниках.
Если вы имели ввиду "что есть сосед" - то соседом пикселя является примыкающий к ребру/вершине
2) "Какой радиус соседства?" - ответ выше
3) "Connected components на GPU - нетривиальная задача" - было непросто и создано не идеально. Могут быть редкие просадки (см. ответ на вопрос 4 выше) и ограничение на глубину. Для целей тестирований пока достаточно.
4) Используется ли union-поиск? - Пока нет
6) "Непонятно, что именно вызывает выбросы: CPU, iOS или Xcode?" - Тема причин расхождения для меня остаётся открытой темой, все ресурсы были выделены на потенциальное улучшение инструмента. Практика показывала - достаточно было сменить версию iOS и простые тесты сыпались.
7) Тесты в обоих реализация настолько быстро проходят, что двукратный прирост производительности из моей реализации не имеет практической ценности - кроме как нескромного заголовка. Проект бенчмарк не сохранился, но когда нибудь, возможно, его воссоздам. Проведу более точные замеры с Delta и выложу в open-source. Добавлю, что Delta2000 вычислительно сложнее чем Delta94. + замеры я стремился провести честно. В бенчмарке использовалась наивная стратегия, а размер изображения был равен iPhone 14 (Эти данные указаны в readme на гитхаб)
Главная победа производительности - это реализация кластерной стратегии. Там ощутимый прирост
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Snapshot тесты для iOS. быстро, стабильно на Metal