Какие размеры изображений вы генерируете и как их отдаёте?

клиенты просят с размерностью

А как размерность просят?

Александр Синицын,
/images/07D2FCF3-46AB-54FC-8895-09C8ED18FD19/1920x1080.jpg
/images/07D2FCF3-46AB-54FC-8895-09C8ED18FD19/1024x576.jpg
/images/07D2FCF3-46AB-54FC-8895-09C8ED18FD19/512x288.png

Андрей,
07D2FCF3-46AB-54FC-8895-09C8ED18FD19 - имя изображения
1920x1080.jpg - размеры

А доступные размеры как-то описываете? Или можно запросить
1921x1080.jpg
1922x1080.jpg
1923x1080.jpg
1921000x1080001.jpg
и они будут все сгенерированы?

Александр Синицын, ну, 1920000х1080000 я не пробовал генерировать, скорее всего, бэк упадет по памяти.

но, если из 16х9 картинки запросят 4х3 - должны добавиться черные полосы сверху/снизу.

Андрей, зачем черные полосы, если можно обрезать изображение правильно.

profesor08, это картинка с камеры, ее нельзя обрезать, потому как камер чуть меньше, чем до фига, а для каждой незначимые области никто отмечать не собирается..

Загружаем фуллсайз в директорию выше webroot. При запросе сервера nginx отдает если есть она в кеше. Если нет - то генерируем скриптом кладем в кеш (доступный в webroot) и отдаем.
Размеры картинок:
1. Ограничить макс.размерами по высоте и ширине.
/images/07D2FCF3-46AB-54FC-8895-09C8ED18FD19/1920x1080.jpg
Плюсы: Легко описать в коде
Минусы: Злоумышленник может нагенерировать тонны мусора. Сменится верстка или еще что и придется править в коде, базе и вообще не тру подход!
2. Реестр размеров
'avatar' => [150,150] // Это сильно упрощенное описание
'avatar-big' => [250,270]
/images/07D2FCF3-46AB-54FC-8895-09C8ED18FD19/avatar.jpg
/images/07D2FCF3-46AB-54FC-8895-09C8ED18FD19/avatar-big.jpg
/images/07D2FCF3-46AB-54FC-8895-09C8ED18FD19/main.jpg
/images/07D2FCF3-46AB-54FC-8895-09C8ED18FD19/preview.jpg
....
Плюсы: Можно управлять размерами централизовано, т.е. поменялась верстка, мы поменяли размеры main и preview и очистили кеш картинок. Все. Ненадо правок в коде. При запросе несуществующих отвечаем 404 - Идите лесом, вас не звали!
Минусы: Немного покодить придется, но совсемм чуть-чуть.
По поводу значимой области - всегда кропать по меньшей стороне и всё. То, что загрузили изображение 1800х10 пикселей не проблема разработчика! Как вариант, если для хранения используется еще и БД, то сохранять смещение от центра или от угла области видимости, как например при загрузке аватарки на ВК.
Еще как вариант параметры к изображению __fill, __crop и на основании их уже генерировать превьюшку кропнутую, заполненную или еще что.

Mylistryx, спасибо за подробный ответ. Пробую сделать, но что-то идет не так. Можете подсказать почему?
Как сделать редирект без редиректа htaccess в корне, чтобы сработал контроллер в приложении frontend?

Александр Синицын, я в этом плане вообще не заморачиваюсь, у меня у меня в nginx:
try_files $uri $uri/ /index.php$args
а уже в роутах я описываю параметры для картинок, причем через немного кастомизированный GroupUrlRule

$rules['files'] = new GroupUrlRule([
'prefix' => 'thumbs',
'routePrefix' => $routePrefix,
'host' => '@hostFiles',
'rules' => [
.....
[
'pattern' => PATTERN_ID . '/_.',
'route' => 'file/thumbs',
'alias' => '@thumbs',
'suffix' => false,
],
.....
],
]);
это пример из старого проекта и не факт что он рабочий. GroupUrlRule принимал еще параметр alias чтоб генерировать алиасы для роутов. Получались "именованные" роуты по типу зенда, и изменив роут ненадо было по коду ничего менять, да и если надо было менять, то по алиасу искать всяко проще.
Думаю понятен смысл? Если файла не существует, то nginx проваливался в PHP и там срабатывало правило которое генерировало превью под заданные параметры. В данном случае способ обрезки брался из URL.
PATTERN_ID мы выносили в константу, там тупо . Так писать было удобней, особенно когда роутов сотни.

Mylistryx, ну, реестр не очень хороший вариант, проще уж проверить, чтобы больше оригинальной ширины и высоты * 2 не запрашивали.

Андрей, поменялся в верстке размер изображения на странице, а в статьях у вас в БД получается записано /images/xxx/320x240.jpg. А так /images/xxx/main.jpg образно. Вот и получается, что старые статьи не поломались по верстке. Нам пригодилось это и не раз. Делали-делали, херакс, макет подправили на несколько пикселей. Поправили в конфиге, сбросили кеш и все а ажуре. Ну и варианты с ограничениями по высоте и ширине: надо выводить картинку 1920х1080 к примеру, скриншот показывать. 1920 * 1080 это больше 2 000 000 вариантов, это если ограничено по таким размерам, а если 2хширина и 2х высота, то это уже 8 000 000+ вариантов. Как думаете, я могу очень хорошо озадачить ваш сервер простеньким скриптом? А если нумерация изображений сквозная, то я могу его заставить вообще работать на меня генерируя превьюхи. А если это какой нибудь хостинг с оплатой за ресурсы? Вот то-то и оно! так что фиксированный именованный реестр превьюх - это вопрос времени )