Теория и практика создания миниатюрных изображений

[Rumata]

Теория и практика создания миниатюрных изображений

Надеюсь, что модераториат форума не будет возражать против данной темы.

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

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

Впервые статья была опубликована здесь - http://debugger.ru/articles/thumbnails

 

[kruglov]

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

Есть мнение, что от переполнения памяти это не сильно поможет.

 

[Rumata]

Возможно.

В процессе подготовки статьи витали призрачные мысли использовать "грубую" imagecopyresized при "слабом" уменьшении больших изображений. Но где граница между большой и не очень большой и "слабое" и "сильное" уменьшение?

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

 

[Фанат]

по-моему, это какой-то детский лепет.
основательное исследование арифметики уровня 4 класса средней школы.

"метод максимального сжатия" назван неправильно. это метод ПРОПОРЦИОНАЛЬНОГО сжатия.
Единственный метод, который гарантирует, что уменьшение в автоматическом режиме не испортит картинку.
Остальное все - для количества текста из пальца высосано.

Особенно последний метод, который неправильно назван(он не сжимает, а обрезает), является частным случаем второго, и иллюстрация у которого тоже неправильная - пунктиры идут от краев картинки, а не от обрезаемых частей (как во втором пункте).
В описании метода фигня. не "сжать меньшую" , а "ОБРЕЗАТЬ большую".

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

чушь!

осмысленность применения каскадного способа вызывает большие сомнения.

самое ценное в статье - PSyHi

 

[fixxxer]

введение офигенное я прям подумал что там дальше высшая математика, с этими, как их, интегралами всякими

 

[WP]

Ну и не лень же человеку писать так много букав было...

 

[SiMM]

> Полагаю, что занесение ее в закладки пользователей ресурсов типа delicios и habrbabr, а также явная ссылка на форуме ru-board - верный признак основательности исследования.
Тоже мне, показатель.
http://php5.ru/articles/image#size куда полезнее.

 

[WP]

Невольно вспомнился баян - мануал по использованию туалетной бумаги на несколько страниц.
SiMM
+1

 

[kruglov]

В процессе подготовки статьи витали призрачные мысли использовать "грубую" imagecopyresized при "слабом" уменьшении больших изображений. Но где граница между большой и не очень большой и "слабое" и "сильное" уменьшение?

Ну, я у себя в CMS использую эту идею уже года 2-3 как для генерации превьюшек на лету чисто для админа. Условно, 2000x1000 уменьшаю через resized до 500x250 и потом до 100x50 через resampled. Идея работает (картинка выглядит немногим хуже, чем в случае чистого resampled), но дает знатный выигрыш в скорости (а не в памяти).