Комментарии 11
Особенно хорошо вышли ссылки в скриншотах таблицы. Неужели так сложно было их перевести и сделать живым текстом? :(
Правильно, EXIF придумали идиоты, поэтому давай ради двух килобайт безжалостно вымараем из картинки дату, гео и прочие незначительные детали. Эмпирические данные внезапно показали, что thumbnail лучше resize.
Я бы как минимум добавил бы уточнение, что после такой обработки картинка станет хуже распознаваема поисками.
Я бы как минимум добавил бы уточнение, что после такой обработки картинка станет хуже распознаваема поисками.
Проблема EXIF данных заключается в том что они пишутся не только фотоаппаратами, но и различными редакторами и конвертерами. 2 КБ это не много для картинки в 100 КБ, но для иконки 0.5 КБ лишний багаж в 2 КБ просто ни к чему.
Что до поиска, то сомнительно прямое использование EXIF данных в поиске, если только вы туда специально ключевые слова не пишете. В отдельно взятых фото- задачах это действительно полезная вещь, но в большинстве случаев нет.
Статья интересная, подобным приемом с пастеризацией и последующим дизером раньше (в начале 2000-х) пользовались верстальщики газет и журналов, чтобы фотографии в 300dpi хоть как-то вмещались на 100 Mb Iomega Zip :)
Что до поиска, то сомнительно прямое использование EXIF данных в поиске, если только вы туда специально ключевые слова не пишете. В отдельно взятых фото- задачах это действительно полезная вещь, но в большинстве случаев нет.
Статья интересная, подобным приемом с пастеризацией и последующим дизером раньше (в начале 2000-х) пользовались верстальщики газет и журналов, чтобы фотографии в 300dpi хоть как-то вмещались на 100 Mb Iomega Zip :)
Я говорил строго про использование thumbnail вместо resize потому… ну, просто потому, что автор не понимает, чем изображение отличается от превьюшки.
Не знаю, что там сомнительного, поиски по картинкам всех крупных игроков явно используют дату и гео.
«Я покрутил ручки настройки и получил картинку меньшего размера» — это годный твит, код на баше как раз прекрасно помещается в 140 символов. От статьи я ожидаю, как минимум, что ресайз не поломает мне нафиг всю привязку к картам и календарю.
Не знаю, что там сомнительного, поиски по картинкам всех крупных игроков явно используют дату и гео.
«Я покрутил ручки настройки и получил картинку меньшего размера» — это годный твит, код на баше как раз прекрасно помещается в 140 символов. От статьи я ожидаю, как минимум, что ресайз не поломает мне нафиг всю привязку к картам и календарю.
>-colorspace sRGB
И сразу получаем неправильную цветопередачу если у нас в оригинале CMYK (независимо от того, есть вшитый профиль или нет. К тому же судя по порядку аргументов встроенный профиль будет сначала удален)
И сразу получаем неправильную цветопередачу если у нас в оригинале CMYK (независимо от того, есть вшитый профиль или нет. К тому же судя по порядку аргументов встроенный профиль будет сначала удален)
Как использовать php imagick на обычном хостинге?
Куча вещей вообще не рассмотрены.
Например, ничего не сказано о параметре -sampling-factor для JPEG, который будучи установлен в 1x1 (вместо стандартного 2x1), позволяет на изображениях некоторого типа применять более сильную компрессию (параметр -quality) с визуально менее различимыми артефактами.
Писать просто "-resize 300" — зло, если речь идет именно о ширине, нужно писать «300x», плюс есть еще модификаторы, которые позволяют не увеличивать картинки меньшего размера, чем указан, и наоборот.
Как-то вообще ничего не сказано о том, что изображения многократно большего разрешения могут быть уменьшены уже на этапе чтения (не для всех форматов это имеет смысл). Также, если нужно сразу несколько экземпляров разного разрешения, те, что максимально отличаются между собой (в разы) можно генерировать одной командой используя -write, экономя на операции чтения исходного изображения и на последовательном уменьшении. Например, для подготовки нескольких изображений под обычные и high dpi экраны, чье разрешение различается более чем в два раза, это как раз идеально подходит.
Например, ничего не сказано о параметре -sampling-factor для JPEG, который будучи установлен в 1x1 (вместо стандартного 2x1), позволяет на изображениях некоторого типа применять более сильную компрессию (параметр -quality) с визуально менее различимыми артефактами.
Писать просто "-resize 300" — зло, если речь идет именно о ширине, нужно писать «300x», плюс есть еще модификаторы, которые позволяют не увеличивать картинки меньшего размера, чем указан, и наоборот.
Как-то вообще ничего не сказано о том, что изображения многократно большего разрешения могут быть уменьшены уже на этапе чтения (не для всех форматов это имеет смысл). Также, если нужно сразу несколько экземпляров разного разрешения, те, что максимально отличаются между собой (в разы) можно генерировать одной командой используя -write, экономя на операции чтения исходного изображения и на последовательном уменьшении. Например, для подготовки нескольких изображений под обычные и high dpi экраны, чье разрешение различается более чем в два раза, это как раз идеально подходит.
Я не увидел считает ли он DSSIM и чем, в таблице этих данных нет.
И не понимаю, что значит «Photoshop CC, with optimization». Он сохраняет из фотошопа в jpeg, а затем ещё раз прогоняет через imagemagick?
И не понимаю, что значит «Photoshop CC, with optimization». Он сохраняет из фотошопа в jpeg, а затем ещё раз прогоняет через imagemagick?
«Я упоминал оптимизацию» — выше по тексту нет упоминаний про оптимизацию.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эффективное изменение размера картинок при помощи ImageMagick