Новое в версии 1.0. Работа с изображениями

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

Во-первых, обеспечена поддержка всех php-библиотек работы с изображениями: кроме GD, это еще Imagick и Gmagick. Известно, что две последние библиотеки обеспечивают более качественную обработку изображений. Если сайт у вас работает на выделенном сервере, и вы можете его настраивать по собственному вкусу, то вы можете установить на нем нужную библиотеку и сконфигурировать движок так, чтобы он работал именно с ней.

Если же вы не разбираетесь в таких тонкостях, то вам можно об этом не задумываться – движок сам выберет наилучшую из установленных библиотек и будет работать с ней. Во-вторых, в новой версии движка реализован механизм обработки изображений налету. Изменение размеров изображения, вырезание части изображения (или говоря сленгом – «кроп» картинки) – все это движок умеет выполнять автоматически в момент запроса.

Поясню это на примерах.

Раньше, при загрузке аватары пользователя делалось сразу несколько ее размеров (обычно это 100x100, 64x64, 48x48 и 24x24). И в разных местах шаблона вы указывали, аватару какого размера нужно выводить. А что делать, если меняется дизайн, и хочется выводить аватары другого размера? Например, 80x80 или 32x32? А ничего тут уже поделать было нельзя – выводи то, что есть.

В новой же версии аватара пользователя сохраняется в том виде, в каком загружается. И в шаблоне вы можете указать вывод аватары любого размера, и нужный размер будет сгенерирован автоматически. Указали, скажем в шаблоне
<img src="{$oUser->getAvatarUrl(78)}">
... и получили аватару размером 78x78. А если указать
<img src="{$oUser->getAvatarUrl(42)}">
... то будет автоматически сгенерирована (если нет еще такой) и выведена аватара размером 42x42.

А можно еще указать в конфигурации скина такой параметр:
$config['module']['user']['profile_avatar_size'] = 120;
Тогда вызов метода getAvatarUrl() без параметра будет возвращать аватару с размером по умолчанию 120x120.

То же самое касается и фотографии профиля пользователя.

Но это еще не все!

Допустим, у вас есть загруженная пользователем картинка /uploads/images/000/picture.jpg. И вам нужно вывести эту картинку, вписав ее в определенные размеры, например 200x100. Раньше вам, пожалуй, пришлось бы для этого писать целый плагин. Сейчас же это сделать чрезвычайно просто! Достаточно просто указать такой URL: /uploads/images/000/picture.jpg-200x100.jpg

И в этом случае движок создаст производную картинку от исходного изображения размером 200x100 и сохранит ее в той же папке под именем picture.jpg-200x100.jpg! Все, вы получили картинку нового размера, которая уже и будет вставляться в HTML-страницу!

Опишу, какие еще производные картинки могут создаваться налету. Допустим, есть изображение picture.jpg с исходным размером 300х200, тогда от него могут создаваться такие производные:

picture.jpg-100x100.jpg – создается изображение размером 100x100 и изображение вписывается в эти размеры по центру, т.е. реальный размер нового изображения будет 100x100, для картинок с цветом прозрачности, пустота останется прозрачной, для других — заполнится цветом по умолчанию (обычно — белый)
picture.jpg-100x100-fit.jpg – создается изображение, при котором максимальная сторона вписывается в заданные размеры, т.е. реальный размер нового изображения будет 100х67
picture.jpg-100x100-pad.jpg — создается изображение, при котором минимальная сторона вписывается в заданные размеры, т.е. реальный размер — 150х100
picture.jpg-100x100-crop.jpg — сначала выполняется операция «pad», а потом обрезка центральной части изображения до заданных размеров, т.е. реальный размер 100х100
Чего в новой версии нет в части работы с изображениями:
1. Нет и не будет скругления уголков. В наше время это выполняется с помощью css и я не вижу необходимости выносить эту операцию на уровень модуля.
2. Нет пока наложения водяного знака (но нужно ли это «из коробки»?).
3. Не поддерживается пока работа с анимированными GIF-картинками (а это, наверное, нужно).

Вообще, потенциал у нынешнего модуля изображений чрезвычайно большой, но я не думаю, что нужно прямо в «коробке» задействовать его на все 100%. Полагаю, что для большинства сайтов реализованного функционала достаточно. А расширенный функционал обработки изображений можно реализовать уже плагином, который будут ставить те, кому это действительно нужно.

Но мы готовы выслушать мнение сообщества и, возможно, расширить «коробочный» функционал.

Похожие статьи

  • Новое в версии 1.0. Собственные типы блогов без программирования
    Одним из ключевых изменений в новой версии движка я считаю возможность создавать и всячески жонглировать типами блогов. Те, кто знаком с ЛС знают, что там были блоги персональные, коллективные и закрытые. И все. И...
  • Новое в версии 1.0. Работа с изображениями (Часть 2)
    Я уже писал о том, что нового вас ждет в версии 1.0 в области работы с изображениями. Но это еще не все! Мы постарались в новой версии решить еще ряд наболевших проблем, связанных с загрузкой изображений. Известно,...
  • Новое в версии 1.0. Структура папок и статические файлы
    Этой статьей я хотел бы начать серию публикаций о том, что нового вас ожидает в версии 1.0 Alto CMS. Долго думал, как бы выстроить изложение так, чтоб эти статьи были полезны разработчикам и понятны всем прочим. Но...
  • Alto CMS — финальный релиз версии 1.1
    Вот и дождались — версия 1.1.0 вышла в релиз. Кратенько о нововведениях в этой версии: Меню сайта вынесены в отдельные сущности и теперь вы можете настраивать их из админкиЕще нововведение: сниппеты (в некоторых...

52 комментария

0
Отлично.
Сохранение анимации очень важно. Для чего ее, тогда создают? :)
0
отлично, наконец-то без помощи плагина мэйнпривью!
супер!
+2
Отличная новость ) Но возникает несколько вопросов

— есть возможность показывать оригинал изображения по клику во всплывающем окне?
— на мой взгляд ватермарк должен быть из коробки такого вида sitename.com/username (имя пользователя загрузившего изображение) это минимальный функционал, если человек хочет большего функционала, тогда ставит плагин, как вы считаете*
— будет ли управление изображениями? Например такое altocms.ru/blog/ideas/244.html или любое другое решение этой старой лайвстрит проблемы?

По поводу поддержки gif — можно выпустить автомобиль и не поставить на него одно колесо, вроде как бы автомобиль есть, все работает, но ездить на нем нельзя ))

И еще pad, fit и т.д я так понимаю надо прописывать руками, ни о какой визуализации процесса обрезки и изменения размеров речь не идет? Если это действительно так, я конечно как админ могу это запомнить, но боюсь пользователи нет )))
0
Я ждал этих вопросов! ;)

… есть возможность показывать оригинал изображения по клику во всплывающем окне?
… будет ли управление изображениями? Например такое…
Будет, но в следующей версии. Сейчас реализован бекенд, без которого данный фронтенд не возможен был в принципе. То же касается и визуализации ресайзинга и кропа. Но уже сегодня этот функционал может использоваться в разработках

Про GIF услышал. Насчет ватермарк пока сомневаюсь, но может быть…
0
Т.е по сути эта версия будет фреймворком для разработчиков, для реализации с использованием коробочного функционала — ждем следующую версию?
0
Тут, пожалуй, не помешает провести четкую грань между фреймворком и тем, что подразумевается под «коробочным функционалом», иначе это больше похоже на популизм. Если «коробочный функционал» — это все действия в один клик из админки — то это скорее нерационально.
А что касается конкретного примера с изображениями, то уже сейчас ничего программировать, как в чистом фреймворке(ну и ЛС) для того, чтобы сделать новый размер фото — не нужно будет. Нужно — в шаблоне однократно указать верные выводы размеров в нужных местах и все будет генерироваться на лету, это уже сокращает работу создателя шаблона во много раз и позволяет ему не касаться кодинга (К слову, подобной работы по настройке шаблона не избежать даже в самых-самых «коробочных» цмсках).

PS Насчет сущности бытия: «фреймворк ли Альто или CMS?» — CMS(+F)
0
Если «коробочный функционал» — это все действия в один клик из админки

Это общепринятые принципы любой CMS на 2013 год — все действия в несколько кликов из админки. Покажите CMS в которой не так, кроме livestreet (который по сути в большей степени фреймворк, чем CMS).

уже сейчас ничего программировать, как в чистом фреймворке(ну и ЛС) для того, чтобы сделать новый размер фото — не нужно будет
у нас на 0.5 ls (модифицированная) за это отвечает плагин на jquery. Хотя здесь наверное стоит отметить, что все действия выполняются с оригинальным изображением, делать несколько копий с разными размерами он не умеет, да и нужно ли это?

Imagick и Gmagick — вот это действительно очень хорошая новость.
0
Я бы, пожалуй, поспорил относительно всех действий. То, что админка нужна — это вообще не обсуждается. Но вот вынос абсолютно всех настроек в нее — это очень сомнительно. Наверное, все же, должен быть какой-то разумный компромисс — что-то в админке в пару кликов настраивается, а что-то — ручками в конфиге. И найти этот компромисс — ох, какая непростая задача, чтоб новичок не стал шарахаться от моструозной админки.

Кстати, подумываю о статье (или даже о серии статей «Конфигурация сайта на Альто — тонкие настройки»), ибо в конфиге громадное число параметров, людям неведомых (даже с ЛС оставшихся, не говоря уж о новых), и которые, скорее всего, не попадут в админку (во всяком случае — в ближайшее время).

делать несколько копий с разными размерами он не умеет, да и нужно ли это?
А как без этого реализовать «возможность показывать оригинал изображения по клику во всплывающем окне?»
0
Наверное, все же, должен быть какой-то разумный компромисс — что-то в админке в пару кликов настраивается, а что-то — ручками в конфиге.

Я просто сомневаюсь что существует на сегодня сообщество в котором юзеры могут руками делать кроп, фит, пад,… Это замечательно для разработчика и возможно отчасти для админов, которые будут использовать эту функцию, а значит — это больше фреймворк релиз. Для пользователей ждем следующий релиз?

Кстати возникает еще вопрос, если эта функция исключительно для админа, то как сделать /uploads/images/000/picture.jpg для всех изображений загруженных пользователями /uploads/images/000/picture.jpg-200x100.jpg?

А как без этого реализовать «возможность показывать оригинал изображения по клику во всплывающем окне?»

Конкретно в нашем случае используется одно и то же изображение с разными размерами сторон. Но, наверное вы правы — правильно делать отдельное превью.
+1
Алена, честно скажу: я, наверное, не очень понимаю, о чем именно Вы говорите. Если речь конкретно про данный функционал — ресайзинг и кроп картинок — то да, пока в диалоговом окне вставки картинки в топик нет возможности указать желаемые размеры. Но вообще изменения в версии 1.0 не только с изображениями связаны.

… как сделать /uploads/images/000/picture.jpg для всех изображений загруженных пользователями /uploads/images/000/picture.jpg-200x100.jpg?
Я не вижу смысла ресайзить все картинки, которые уже лежат на диске. Их можно (и в большинстве случаев нужно) ресайзить непосредственно в момент вывода. Если, например, у вас где-то стоит вывод изображения:
<img src="/uploads/images/000/picture.jpg">
то вы можете указать в этом месте
<img src="/uploads/images/000/picture.jpg-200x100.jpg">
и движок автоматически сгенерит и выведет картинку нужного размера. Если за вывод в шаблоне у вас отвечает код типа:
<img src="{$oTopic->getPictureUrl()}">
то вы можете его в таком виде представить:
<img src="{$oTopic->getPictureUrl()}-200x100.jpg">
Хотя я предпочитаю такие вещи лучше на уровне сущности отрабатывать, а не в код шаблона вшивать
+1
Конкретно в нашем случае используется одно и то же изображение с разными размерами сторон. Но, наверное вы правы — правильно делать отдельное превью
Если изображений не очень много и/или их оригиналы не очень большие, то можно и одно изображение использовать. Но вообще разница есть — изображение 1000х800 и, скажем, 250х200. Сейчас для всякого рода альбомов и проч. часто используется код что-то типа такого:
<img src="picture.jpg-200x100.jpg" data-image="picture.jpg">
Т.е. в HTML-страницу встраивается мини-картинка (picture.jpg-200x100.jpg), при клике на которую уже открывается большое изображение picture.jpg.

И на большом трафике и/или при работе с большими фотоальбомами отдельное превью может дать очень хороший положительный эффект
Отредактирован:
+1
Насчет ватермарк пока сомневаюсь, но может быть…
По поводу ватермарка считаю, что он тоже должен быть из коробки. А то, что бы уникальные фото не ушли в просторы интернета, пользователям придется вручную их ставить. А это вовсе неудобно.

Будет, но в следующей версии.
Ну и как всегда не хватает управление картинками. Будем ждать.
0
А что, на Ваш взгляд, должен представлять из себя ватермарк? Как Алена предложила? Или что-то иное? Что у Вас ставят пользователи?
0
Обычно ставят свои копирайты. Видел на форумах такой вид, думаю он лучше будет:

Автор(ник на сайте) для site.ru

например: garri83 для altocms.ru

Хотя можно сделать отдельное поле в профиле для имени для ватермарка, как есть для названия персонального блога, но возможно это и лишнее 8)
Отредактирован:
0
Почему именно адрес блога или профиля пользователя — так пользователи с бо/льшим желанием делятся такими изображениями на других сайтах.

Но конечно в идеале опционально.
0
Я считаю вотермарк полезной штукой только для тех сайтов, где авторы используют исключительно свои изображения, а не стиснутые с интернета.
Отредактирован:
+1
Ну вот да, как именно по умолчанию помечать загружаемые картинки — это тоже вопрос. Алена предложила вариант, но я чаще встречал, что пишется просто адрес сайта (без указания юзера) либо логотип сайта. Пока я склоняюсь к тому, что лучше плагин отдельный написать, где будет множество разнообразных настроек для того, чтоб «метить» загружаемые фотки
0
Тоже поддерживаю идею насчет сохранения анимации в GIF картинках, очень много движков и форумов почему то сохраняют и нормально отображают без пережатия Gif. Чем Alto хуже?
0
Версию на гитхабе, уже можно использовать для действующих проектов?
0
Ну, официального релиза еще не было — так что, по идее, еще не желательно.
0
Так Альто же поддерживает ватермарк. Его вырежут в 1.0?
А сохранение gif анимации у меня получилось сделать и весьма не сложно, возможно «костыльно» но работает. Хочется ещё чтоб анимация проигрывалась по клику, как Вконтакте, ато когда гифки сразу подгружаются, увеличивается время загрузки страницы, а это не есть гуд.
0
Ну, вы не забывайте, сколько времени вконтактик шел к этому — а тут в версии 1.0 сразу реализовать все фишки точно не получится.
0
Да я примерно уже знаю как сделать по клику, только ещё не совсем разобрался с движком.
Может кто подскажет место, отвечающее за вывод в пост чтоб например прописать alt или title, чтоб не искать?
Отредактирован:
0
Вывод изображений. Я не про шаблон.
0
По клику вообще было бы здорово! Мозила просто падает этот переизбытка флеша на странице
0
Думаю, самый главный вопрос по работе с изображениями — это так называемая «расширяемость». Что я имею в виду. Например, делаю я плагин, в котором идет своя работа с изображениями. Соответственно, мне необходимо заново написать все функции работы с изображениями + придумать для них способ хранения + протестировать весь заново написанный функционал. Идеальный вариант — когда я просто пользуюсь методами работы с изображениями, уже существующих по дефолту в движке, и мне не нужно решать выше описанные проблемы.
Будет ли данная проблема решена? Это очень упростит разработку.
Отредактирован:
+1
Будет ли данная проблема решена?
Я считаю, что в новой версии такой проблемы нет в принципе. Модуль работы с изображениями был не просто «доработан», он был написан полностью с нуля — новая архитектура, новый набор методов. Я даже назвать решил его иначе, чтобы путаницы не возникало (старый — ModuleImage, новый — ModuleImg).

Сейчас в модуле реализованы базовые функции: resize и crop, будут еще flip и rotate (точнее, уже есть, только методы в интерфейс модуля не вынесены). Ясень пень, поддержка GIF-анимации тоже будет. Причем, операции все конентно-независимые, т.е. неважно, с каким изображением работаете — аватара, фотка в топике и т.д. Просто передается либо объект-изображение (который может быть создан как сам по себе, так и из файла), либо имя файла с картинкой, над которым выполнить операцию нужно.

Короче, я не могу себе представить, чтобы Вам потребовалось теперь в плагине полностью переписывать функционал работы с изображениями
0
За хранение изображений мне тоже не нужно отвечать (т.е. смогу ли хранить изображения в том же хранилище, где их хранит Альто)? Если, например, с помощью моего плагина пользователь загружает изображения для дальнейших каких-либо действий (например, тот же плагин miniMarket, где необходимо добавлять картинки к товарам).
+1
Поскольку загрузка и хранение файлов вообще — это отдельный пул задач, не связанный напрямую с обработкой изображений, то этим занимается новый модуль под названием Uploader.

В простейшем варианте (если нужно просто загрузить изображение без какой-либо обработки) это может выглядеть примерно так:
// получаем параметры загружаемого файла
$aFile = $_FILES['image'];

// получаем папку хранения изображений для юзера $oUser
$sTargetDir = $this->Uploader_GetUserImageDir($oUser->GetId());

// загружаем файл
$sImageFile = $this->Uploader_UploadLocal($aFile, $sTargetDir);
В результате будет выполнена проверка, действительно ли файл был загружен через POST и не было ли каких ошибок при загрузке, создаст целевую подпапку в нужном месте, если ее еще там нет, подберет уникальное имя файла (если в этой папке есть уже файлы) и переместит загруженный файл в эту папку с уникальным именем и вернет его полный путь в переменной sImageFile.

Если нужно получить URL для этого файла, то в этом поможет такой код:
$sImageUrl = $this->Uploader_Dir2Url($sImageFile);
Если нужно не через POST загрузить картинку, а взять ее по URL, то вместо метода UploadLocal($aFile) можно использовать метод UploadRemote($sUrl).

Есть и более низкоуровневые метода, если, скажем, нужно сначала во временную папку загрузить файл, потом что-то с ним сделать, а потом уже отправлять на хранение.

Так годится?
+1
Не трави душу, чертяка, релизьте скорей! )

На самом деле столько вкусного, что я думаю через неделю-другую начать переносить с ЛС проект на Альту, в рамках «посмотреть, потыкать, сделать наработки для перехода»
+1
Вадим, спасибо за развернутый ответ. Если все будет работать примерно так, как описано — то это сильно упростит работу разработчикам.

П.С. Если у вас стоит выбор перед тем каким путем идти — делать быстро но плохо или долго но хорошо — то делайте хорошо, я готов ждать.
0
Постараемся все же делать хорошо, но не очень долго :) Пока мы опытным путем нащупываем правильное соотношение числа новых фич к релизу
0
Вопрос по безопасности. Что если какой-то недоброжелатель будет делать автоматические GET запросы ко мне на сайт вида:

picture.jpg-1x1.jpg
picture.jpg-2x2.jpg
picture.jpg-3x3.jpg

То каждый раз будут генериться и сохраняться новые изображения?
В таком случае через какое-то время диск переполнится и сервак накроется.
0
Чтоб накрылся сервак, таких запросов должно быть очень много. А это уже сродни с ДДоС-атакой, и ее отсечение должно решаться не на уровне движка.

Впрочем, если есть идеи, как улучшить логику на уровне движка — готовы выслушать
0
Например создавать эти изображения непосредственно при публикации (статьи, комментария).
+1
Есть сайт, где ширина зоны топика в старом дизайне была 540px, а сейчас она — 620px, но все ранее загруженные изображения так и остались на 540, а новые грузятся с шириной 620. Аватары в старом дизайне были 80px, а в новом их дизайнер нарисовал 120px. И размеры в фотосете изменились. Но если с кастрированными картинками в топике как можно было смириться (хотя и не очень хорошо это смотрится), то с аватарами и фотосетом ничего поделать было нельзя, кроме как писать специальный срипт, который бы перелопатил все аватары и фотки фотосетов. Пришлось творческий полет дизайнера прервать, и заставить его аватары и фтосет рисовать не в тех размерах, как ему кажется правильным с точки зрения дизайна и юзабилити, а в тех, в каких они есть сейчас.

Изложенный в статье подход решает эту проблему на счет «раз».
0
Тогда, altocms.ru/blog/dev/420.html#comment6852

Вообще вопрос стоял как не отдавать по get запросу

picture.jpg-1x1.jpg
picture.jpg-2x2.jpg
picture.jpg-3x3.jpg
altocms.ru/blog/dev/420.html#comment6827

В недобросовестных руках это может стать настоящей проблемой. Что помешает создавать picture.jpg-10000x10000.jpg к примеру или тысячу picture.jpg-100x100.jpg? дисковое пространство закончится очень быстро.

Объясню почему это гораздо хуже ддос атаки — с помощью простого скрипта генерящего 100 картинок в минуту конкурент сможет заполнить все дисковое пространство за несколько часов. И для этого будет достаточно одного ПК.
0
Алена, я понял проблему. На самом деле все чуть-чуть сложнее, но суть ясна, работать есть над чем. А про get-запрос я уже писал — это не прописано жестко в движке и отключается элементарно в конфиге
0
Идея хорошая, но прошу сделать эту опцию отключаемой. По мне так разовая перегенерация картинок куда безопаснее. Ее можно сделать и локально и во время спада посещаемости на сервере
+1
Отключается элементарно — комментированием одной строки в конфиге
Отредактирован:
0
Решение проблемы, описанной пользователем kovaldo , может быть следующим: рендерить картинку нужного размера только в том случае, если идет обращение через некий объект. Например, если встречается подобная конструкция в шаблоне:
{$oUser->getAvatar('100x100-pad.jpg')}
А вот когда идет просто GET запрос к файлу картинки — то выдавать только то, что есть уже на сервере.
Я понимаю, что такой подход может добавить много геморроя, и из-за некоторых особенностей, которых я мог не заметить, такой подход вообще может не сработать — но злоумышленник в самом деле может воспользоваться данной «фишкой» в своих целях. Не обязательно ддос-ить сайт — можно «потихоньку» обращаться к файлу — и его клоны будут занимать свободное место. Возможно, это проблема надуманная, и злоумышленнику надоесть действовать подобным образом, но все же этот вопрос необходимо как-то решить.
0
Предложение заслуживает внимания, спасибо
0
Лог подобных запросов ведется в базе данных?
0
Нет, таких логов не ведем. И я думаю, что если их даже и вести, но не в базу писать, а просто в файл. Не вижу смысла базу этим грузить
0
Жаль, что ваш вектор безопастности так сильно смещен
+1
Объясните, плиз, куда он смещен? Я же выше написал: если для Вас это принципиально, то убираете одну строку из конфига — и не будут никакие картинки создаваться налету, все будет жестко и элементарно — либо картинка есть уже готовая (тогда отдается), либо нет (тогда error 404 без вариантов). Куда уж безопаснее?
0
Я не вижу смысла ресайзить все картинки, которые уже лежат на диске. Их можно (и в большинстве случаев нужно) ресайзить непосредственно в момент вывода.

Правильно ли я понимаю, на диске будет храниться ТОЛЬКО оригинал. При выводе КАЖДАЯ картинка будет ресайзиться отдельно? Если это так, не создаст ли это диких нагрузок на сервер и задержек в производительности. Скажем, если у меня есть фотосет со 100 фотографиями и его смотрят одновременно 20 человек.
+1
Правильно ли я понимаю, на диске будет храниться ТОЛЬКО оригинал
Нет, не правильно. Тут речь о том, что в большинстве случаев нет необходимости для всех изображений, лежащих на диске, заранее создавать все размеры, которые потом могут пригодиться. При обращении, если нужного размера нет, то выполняется ресайз и новое изображение сохраняется. При повторном обращении отдается картинка, созданная раньше.
0
А зачем делать независимые аватары в профиле пользователя? Лишние телодвижения для пользователей. Еще при загрузке изображение в другую папку продублировалось в другом формате. Так должно быть? Кстати, при загрузке нет индикатора загрузки.
0
Еще интересный нюанс, в топике нельзя посмотреть изображения в оригинальном размере.
0
Или я не… или лыжы не катят.
Проблема в следующем не pad, не crop, пробовал по разному все равно квадратом или с белым фоном, что не совсем то, что нужно, остановился на
getPhotoUrl('650x')


Но это еще не главная проблема, при загрузки, скажем фото профиля оно сразу урезается в размерах которые мне не нужны ( 240х320 ) и с белым фоном, но после перезагрузки страницы все норм, как и прописано в шаблоне ( 650 в ширину ).
Собственно сам вопрос. Возможно ли в шаблоне (start-kit), не прибегая к изменению системных файлов или иных не относящиеся к шаблону решить эту проблему?

Для более точной понятия моей проблемы прикрепляю скрин, что происходит сразу полсе загрузки (изображение по идее во всю ширину и без белого фона)
0
Вадим хотел бы уточнить…

Правильно я понимаю что аватарка блога/фото в профиле/аватарка пользователя будут ограничены только вот этим параметром:

$config['view']['img_max_width']    = 5000;     // максимальная ширина загружаемых изображений в пикселях
$config['view']['img_max_height']   = 5000;     // максимальная высота загружаемых изображений в пикселях


И при загрузке ужмутся до соотвествия этим параметрам?

А в шаблоне я смогу выводить их уже согласно вышеописанным модификаторам любые нужные размеры?

2. И второе уточнение, правильно я понимаю что размер изображений (и другие параметры) для топиков уже будут определяться вот этимим параметрами?

$config['module']['image']['preset']['default'] = array(
    'driver' => 'Imagick,GD', // 'GD', 'Imagick' or 'Gmagick', or several libs separated by comma
    'jpg_quality' => 80,
    'watermark' => array(
        'enable' => false,
        'image' => array(
            'path' => '___path.static.dir___/___path.uploads.root___',
            'file' => 'altocms.png',
            'topleft' => false,
            'position' => '0,0',
        ),
    ),
    'size' => array(
        'width' => 700,
        'height' => 700,
    ),
);
$config['module']['image']['autoresize'] = true;

// Нужно ли использовать водяной знак для изображений в топике
$config['module']['image']['preset']['topic']['watermark']['enable']  = false;

// Нужно ли использовать водяной знак для изображений в фотосете
$config['module']['image']['preset']['photoset']['watermark']['enable']  = false;


Т.е. они будут ужиматься до 700x700 с качеством jpeg 80%? И для них также можно использовать вышеописанные методы?

Вот этот параметр уже не работает получается?

$config['view']['img_resize_width'] = 570;      // до какого размера в пикселях ужимать картинку по ширине при загрузки её в топики и комменты
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.