Форум PHP

не совсем. там нет ничего про метод cropThumbnailImage. вот он как раз самый полезный. а вообще да, GD лучше не пользоваться. тормознутая и убогая

Не хочется создавать новой темы? Или все уже решено.

Тем не менее, в качестве размышлений.

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

Если для вас есть смысл в этом, делайте, но экономия трафика сомнительна, если беспокоится только о КБ.

Средствами HTML, это указать атрибутам width, height размеры в процентах меньше 100. Браузер выведет с указанным размером, но реально загружать будет изображения как есть.

Накладно.

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

Какие могут быть проблемы.

Если изображения только удаляется, то проблемы не будет, но если изображения редактируется, например, существующее замещается новым и в случае даже если они у вас "бесхозные", чего в принципе быть не должно, имя должно остаться тем же. А это значит, что заменив текущее фото другим, вы не обязательно увидите новое, браузер покажет старое, из кеша. Особенно в этом плане "лютует" FF.

Такая проблема решается добавлением к имени изображения GET-параметра, в качестве которого выводят текущую на момент выдачи файла метку времени. Но это порождает новую проблему - не будут браться из кеша все файлы, даже те, что не подвергались изменениям. Поэтому в качестве GET-параметра нужно передавать время последнего изменения файла, тогда браузер будет делать запросы только на измененные файлы.

Это в качестве нагрузки, для размышления на будущее.

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

Если что, то только новая тема.

Давайте так - создайте новую тему, в которой опишите это вопрос. Эта тема слишком велика уже, чтобы в ней удобно было "копаться".

а можно ли как то открыть файлы фотографий в худшем качестве например, или в меньшем размере, для того чтобы администратору просто показать какая это фотография (для дальнейшего удаления) ну и главное для экономии трафика?
Т.е. как бы так файл открыть, чтобы не атрибутами width, height тега img размер задавать а реально средствами php его уменьшать (только чтобы прочитать, открыть файл и не делать маленьких копий)

Ну как выводить, с помощью html тега img. Путь известен, обходите директорию, получайте имена и выводите. Можно glob() использовать. Вот только все в известной директории... Все это сколько? И удобно ли их все вывести на странице?

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

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

Нет, сборка тоже 32-битная, хотя машина с ОС 64-бит.

А никто и не говорил, что GD, это нечто тонкое в плане инструмента, есть у нее некие "свои" трактовки и в расчетах фильтров, например неожиданный результат работы новой функции imagesetinterpolation() в зависимости от метода. Или это результат недосмотра, ошибки, или как всегда.

ну а что делать - авторы библиотеки решили, что вся эта экономия им нафиг не срослась. Предположения о запасах на будущее в высшей степени сомнительны. Все куда прагматичнее.
Удобно хранить каждый пиксель в типе int (и вероятно, альфа-канал - в типе char) - они и хранят.
То что при этом не учитываются строгие параметры цветности и кому-то рвет шаблон расходуется изрядное количество лишней памяти - пофиг.
У меня машины с 64-битной сборкой, и возможности поглядеть на поведение кода в такой среде - нет.
Может у Вас есть?

Дошло, суть вопроса - почему библиотека использует более чем.
Не знаю, возможно из расчета на будущее, когда она будет способна работать и с большей глубиной цвета. Но в настоящее время она оперирует только 8-ю битами на цвет, тремя каналами плюс альфа каналом и все. Например, CMYK jpeg она может вообще не открыть.

Ну думаю понятно и то, что открывая ресурс я должен ориентироваться на эти параметра изображения, а если уж "подстраиваться" под библиотеку, то нужно не умножать на 5 или 9, а корректировать не 1.65, а на более реальную цифру. Иначе я не понимаю логики - плюнуть на основные параметры изображения, не рассчитывая по ним необходимую память, а вместо этого сперва открыть ресурс, узнать с помощью memory_get_usage реальное, и только потом принять решение. Поэтому вопросы к чему бит на ресурс, число каналов ... меня удивили.

>Я не понимаю другого, сути этого разговора. Доказать, что библиотеке похер что из себя представляет изображение, то есть его параметры или что?

Да нет, вобщем-то... какой смысл доказывать что-то про поведение открытого кода..
Оно такое, каким является, а не такое, как про него кто-то что-то думает.

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

Это не мои, это Ваши расчеты. Я их всего лишь поправил слегка.
Вернее, изначально я лишь спросил, не ошиблись ли Вы случайно?
Спросил не подколки ради, а потому, что сам довольно давно в предмете пристально не копался, а он - предмет - за те 5 лет, что я в него не лез, мог оказаться и исправлен.
Потом понял, что истина Вас не беспокоит, и ответил на свой вопрос сам.
Сперва эмпирически, а потом - строго по коду.

Что до идеи просто докинуть 65%, не опираясь на логику.
Да, так можно.
Хотя при 64битной сборке на платформе, на которой int займет 64/8 = 8 байт, и выделенный библиотекой размер окажется кратен 9 - не спасет :)