Как подбирать аугментации: гипотезы, протокол и метрики

[sektor305]

Автор подаёт normalization="image" как инсайт от грандмастера Kaggle, эквивалентный RandomBrightnessContrast, но наоборот.
Возникает закономерный вопрос: если это, по сути, просто другой способ сделать то же самое, зачем может понадобиться эта неявная, неконтролируемая форма вместо явной и прозрачно параметризуемой?
Когда и почему один метод аффинного преобразования пикселей должен работать лучше другого?
Тезис о том, что это «бесплатная аугментация», остаётся недоказанным, а механизм её преимущества перед простым тюнингом параметров RandomBrightnessContrast не раскрыт.

[ternaus]

Под нормализацию Per Image у меня действительно нет benchmark’ов, которые покажут где это работает, а где нет.

В этом смысле, действительно со слов Christof’а.

Его утверждение на момент диалога было в том, что в какой-то момент перешёл на нормализацию per_image, причём где-то считал mean и std для каждого канала, а где-то среднее по картинке, и в разных задачах заходило по разному.

И перестал использовать BrightnessContrast и RGShift, и не заметил потери качества.

И тут, с одной стороны - независимых экспериментов я не делал, и он мог выражать субъективное мнение. Аугментации - это только один из типов регуляризаций, обычно используется пачка разных, что-то другое могло компенсировать.

А, с другой, непараметрические аугментации дорого стоят, потому что тюнить как раз очень неприятно, пространство поисков у аументаций дико большое, и какие использовать, и с какми параметрами, и с какими вероятностями применять в пайплайне.

Собственно, весь текст выше как раз про то, что задача и не решена. Есть эвристики, есть идеи и трюки, но стройной теории или хотя бы фреймворка толком нет.

И нормализация per image, как раз один из этих трюков, которые у Christof’а работали, достаточно логичны и, если в задаче работают, позволяют сузить пространство для тюнинга до чуть более приемлемого.

[sektor305]

ясно, благодарю за ответ.