Да, все свертки, которые вы упомянули, могут быть объединены в одну для окончательной реализации.
Однако имеет смысл разделить отдельные требования в пользовательском интерфейсе. Необработанная функция ядра свертки даже для тех, кто обучен таким вещам, трудно получить мысленно или преобразовать во временную область (в данном случае фактически в пространственную область) эффекты. Вам нужно несколько ручек, которые регулируют вещи в концептуальном пространстве человека, а затем под капотом создаются отдельные или комбинированные ядра свертки.
Причина, по которой не комбинируется свертка нескольких эффектов, более вероятна из-за структуры программного обеспечения. Особенно с большим приложением, которое имеет архитектуру плагинов, каждый плагин должен делать свое дело независимо. В главном приложении должны быть специальные ресурсы, которые позволят плагинам добавлять свои специфические модификации в глобальное ядро свертки. И это будет работать только в случае линейных эффектов, которых многие не делают. Единая глобальная свертка также должна быть достаточно большой, возможно, выполняющейся медленнее, чем несколько меньших сверток подряд. Механизм глобальной свертки может посмотреть, как далеко простираются ненулевые данные, но это добавляет больше сложности и больше решений во время выполнения.
Все сказанное иногда объединяет эффекты. Я делаю это в моем собственном программном обеспечении по отображению яркости. У меня есть несколько видимых пользователю элементов управления, некоторые линейные, некоторые нелинейные, но большая часть результата в конечном итоге преобразуется в набор справочных таблиц. Я еще не реализовал резкость, но я, вероятно, сверну это в выходной фильтр. В настоящее время это свертка, используемая для сглаживания при записи в более низкое разрешение.
Добавлено отображение яркости
Мое программное обеспечение допускает несколько способов управления линейными сопоставлениями яркости, а также несколько нелинейных сопоставлений, которые объединяются. Линейные отображения в конечном итоге преобразуются в формат Y = mX + b, несмотря на ряд способов сделать это из пользовательского интерфейса. Нелинейные отображения определяются в терминах логарифмов и экспонент, что потребует очень много времени для вычисления каждого пикселя или каждого отдельного вклада в 2D-фильтр для каждого полученного значения пикселя.
Существует некоторое вычисление, которое необходимо выполнить для каждого значения цвета в целом, но большинство линейных и нелинейных отображений в конечном итоге объединяются в три таблицы поиска, по одной на цвет. Я представляю необработанное изображение внутри с 16 битами на цвет на пиксель. Для современного компьютера три справочных таблицы по 65536 записей в каждой не представляют особой проблемы. При таком относительно небольшом объеме памяти может быть представлено любое произвольное отображение интенсивности входного сигнала на интенсивность выходного сигнала. Таблицы загружаются путем выполнения лог, экспоненциальных и других расчетов. Когда происходит фактическое сопоставление пикселей, все это становится поиском.
Три таблицы поиска для каждого цвета могут обрабатывать только определенные вещи. Некоторые отображения работают с глобальным цветом всего пикселя и не могут быть разделены на независимые отображения R, G и B. Тем не менее, многие могут, и таблицы поиска объединяют любое количество из них, концептуально примененных последовательно и кропотливо рассчитанных в один поиск.