Комментарии 4
Я бы делал совсем иначе - первый и последний пиксель есть случайные величины.
Усреднить цвет по границе изображения на десяток пикселей - человек так видит. Сгладить - получится линия вдоль границы. Расширить её на всю добавляемую полоску - это можно сделать разными способами. Например.
Просто повторить пока полоса не заполнится. Повторять и каждый раз немного сглаживать - изображение будет как-бы выступать.. Переносить цвет по прямым из центра изображения. И так далее…
Не понятно, картинка с уже предложенным Вами градиентом? Похоже, что нет. Попробуйте построить четыре тестовые картинки: 100 пикселов сверху, слева, справа и снизу.
Броюсь что проблема не в том, где лучше делать линейный градиент, в пространстве RGB, или в пространстве HSV, а в самой формулировке идеи дополнения.
например RGB {173, 217, 54}
Правильно ли я понимаю, что вы предлагаете линейно интерполировать промежуточные пиксели для каждого из каналов RGB для достижения градиента?
В таком случае не рекомендую этого делать именно в RGB кодах, так как с большой степенью вероятности в середине градиента будут "средние" по яркости пиксели со значением близким к 128 из 255 в каждом из каналов. Картинка будет отдавать серым грязным оттенком в середине.
Рекомендую перейти к цветовым пространствам, которые описывают восприятие цвета глазом, а не кодирование его для железки. Например, HSL, и сделать интерполирование там. А потом уже можно вернуть обратно в RGB.
Пример градиентов от чисто красного 255, 00, 00 к чисто зелёному 00, 255, 00.
RGB получает в середине 88, 88, 00 что является "оранжеватым" оттенком серого - яркость красных пикселей упала в 2 раза, яркость зелёных - только на половине своей мощности.
HSL получает в переводе на RGB в середине 00, 00, 255 - что является жёлтым - цветом посередине между красным и зелёным в восприятии цвета глазом, причём яркость цвета сохраняется.
UPD: Хотя пространство HSL закольцовано, там может быть 2 градиента - в зависимости от того, в каком направлении по кругу идти. может быть ещё такой вариант - 00,00,255 в середине вместо 255,255,0
Становится много картинок, скрою под спойлер
UPD2: рассмотрите использование библиотеки imagemagic, она повсеместно распространена, портирована на множество языков и даже встроена в php как часть языка. Там все эти проблемы цветовых пространств и красивых градиентов уже решены, не нужно писать свой код.
Если рассматривать это как реальную задачу ("написать сервис"), а не упражнение ("как математически просчитать"), то выглядит страшно, очень страшно. Я бы упростил до:
Растровая картинка с линейным градиентом по двум точкам - это картинка 2x1 пикселя, увеличенная с билинейной фильтрацией (до нужного размера - 1280x853). Ну, нам надо две полосы, можно взять картинку 2x2.
Цвет этих 4 пикселей? Использовать усреднённые цвета исходной картинки по углам. Уменьшить исходник где-нибудь до 5x5[1][2] и взять угловые пиксели.
А если извлечь не угловые пиксели, а верхнюю/нижнюю строки целиком, то будет линейный градиент по 5 точкам.
Чтобы градиент не распадался на полосы, лучше работать в 10+ битах и дизерить при понижении разрядности до 8 бит.
В чём это делать? Взять какую-нибудь высокоуровневую библиотеку для работы с картинками, чтобы из коробки всё было доступно: ресайз с фильтрами на выбор, несколько видов дизеринга плюс интерфейс почеловечнее, чем у imagemagick. Imagemagick можно использовать как Arch Linux не трогать, но пользоваться его документацией с хорошей теорией.
[1] снова можно выбрать билинейную фильтрацию, теперь ради скорости
[2] лучше выглядит, если использовать размер, обратно пропорциональный ширине полос (5x5 для широких полос, 10x10 для узких, условно говоря)
Как математически просчитать градиент цветовой палитры