Оптимизация PNG и JPEG без потери качества. Часть 2

[@Nail13]

Скажите, а возможно ли ваш замечательный продукт трансформировать в онлайн-сервис?
Чтобы было так: я открываю ваш сайт, выбираю файлы, предназначенные для оптимизирования, нажимаю кнопку «отправить» и через некоторое время получаю готовые файлы (ссылкой «скачать»).
Типа вот такого: www.punypng.com/

[@mark_ablov]

основной же лимит видно — процессорное время.
«некоторое время» будет очень большим.

[@Nail13]

Думаю, это не будет проблемой. Если софт умеет прогнозировать время обработки, можно выводить сообщение «ваши файлы будут готовы через… минут. Если не хотите ждать, оставьте ваш e-mail, мы отправим как только будут готовы»

[@Noobster]

А кто оплатит такое количество процессорного времени?

[@Nail13]

Неужели это такая большая проблема?
Способов монетизации существует море. Начиная с банальной рекламы и заканчивая платным сервисом. Тот же PunyPNG за бесплатно предлагает работать с маленькими файлами (до 150 кб), нужно больше — покупай про-аккаунт.

[@Lorents]

Можно попробовать сделать, но мне на данный момент интересует больше создание GUI.

[@Alexvir]

Есть очень хороший, онлайн сервис
smushit.com от Yahoo

[@radist2s]

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

[@novoselov]

Самый лучший результат получается если прогнать png через smushit, а затем punypng. В обратном порядке работает не так эффективно, проверьте на сколько-нибудь значимой коллекции из 100-500 файлов.

[@Lorents]

У него есть один существенный недостаток, нет оптимизации прозрачности PNG

[@ozoned]

Для мака есть удобный ImageOptim, но объединяет PNGOUT + PNGCrush + OptiPNG + AdvPNG + JPEGOptim + Jpegtran + Gifsicle.

imageoptim.pornel.net

Очень удобно держать его в доке и прямо на него «бросать» папку с изображениями.

[@VBart]

Под Linux есть аналогичная штука: Trimage

[@sashock]

Под винду аналогичная PNGgauntlet pnggauntlet.com/

[@Lorents]

лучше используйте, PNGOutWin, он хоть и платный но на много лучше, хотя бы потому что есть параллельная оптимизация.

[@Lerg]

Сравнил
Original: 250kB
GIMP: 127kB
ImageOptim: 118kB
PunnyPNG: 115kB
Здорово, спасибо за ссылку, как раз нужно было.

[@ozoned]

Попробуйте несколько раз запустить обработку, часто и по второму-третьему проходу происходит уменьшение размера.

И еще, PNGOUT нужно дополнительно скачать и указать путь к нему в настройках.

После прогона ImageOptim еще не один сервис не смог дополнительно ужать картинку.
Вот только что прогнал:
Оригинал: 85 437 байт.
ImageOptim: 68 563 байт.
PunyPng: 74 871 байт.

[@Lerg]

И правда. После второго прогона и с включенным pngout
PunnyPNG: 111945 B
ImageOptim: 111908 B

[@ZiNTeR]

Прекрасная идея. А если довести время прогона до бесконечности размер файла будет стремиться к нулю…

На нынешний момент тенденция публикации изображений в сети такова, что важнее скорость, с которой ты отдашь результат, чем срезанные 0.5 килобайт с превью каждой картинки, и 30+ кб с каждого её полного вида.

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

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

Я не хочу сказать «храните и выкладывайте все в BMP» — просто надо четко понимать — временные ресурсы при обработке и выкладке изображений обычно в профессиональной работе сильно ограничены. А преимущество в уменьшении файла на пару килобайт большая часть ваших клиентов не заметит.

В связи с этим двойной и более прогон «мегаоптимизаторами» применим в реальном мире только с целью самореализации на поприще «крутого IT-специалиста».

[@Lerg]

Не сайтами одними едины.
Для мобильных приложений каждый килобайт у картинки считается. Такие оптимизаторы серьёзно уменьшают размер получаемого установочного файла.
А третий прогон, кстати, результата не дал.

[@ZiNTeR]

Не вопрос. Считается.
Но чтобы продолжать аргументированную дискуссию — для начала изучите хотя-бы это:

uibook2.usethics.ru/

Нет большого смысла в внесении кучи «классных изменений», если 80% пользователей их не ощутит на себе. Я не говорю что нужно в принципе отказаться от оптимизации. Но нельзя отводить на неё, к примеру, большее время чем на «удаление красных глаз»…

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

[@Lorents]

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

[@ozoned]

Вы тоже так делаете в Non-interlaced-Xtreme: сравниваете результаты PNGWolf и TruePNG :)

Кстати, на тестовой картинке ваш скрипт показал лучшие результаты (на 188 байт). Скорее всего за счет «грязной прозрачности».

Ну а в целом как ваш скрипт так и ImageOptim отлично решает проблему «ленивой» оптимизации, возможно, подобрав параметры и порядок оптимизаторов для каждой конкретной картинки, добиться лучших результатов, но по-моему не стоит оно того.

[@ozoned]

Не претендуя на абсолютную репрезентативность (выборка из одной картинки :))

Original: 85 454
PunyPng: 75 169
SmushIt: 71 501
PunyPng + SmushIt: 71 316
SmushIt + PunyPng: 69 449
Image Catalyst: 68 627
Image Catalyst (+ColorType, +BitDepth): 68 627
ImageOptim: 68 577
Image Catalyst (+Dirty Transparency): 68 389
Image Catalyst (+ColorType, +BitDepth, +Dirty Transparency): 68 389

[@bolk]

speedupyourwebsite.ru/books/reactive-websites/
Просмотрите третью главу.

[@Lorents]

вопрос, зачем? Я лучше их знаю оптимизацию

[@bolk]

Я один из авторов. Почему вы думаете, что вы лучше это знаете?

[@Lorents]

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

Кстати с этой книгой я и начал изучение оптимизации изображений, поэтому хотел поблагодарить Вас за книжку.

[@bolk]

Вы, видимо, описа́лись и имели ввиду следующее: «простите за мою нескромность, хотя бы потому что Вы в главе 3.3.3 сравниваете приложения, а это категорически нельзя делать, по моему мнению». :)

За благодарость — спасибо :) Значит не зря мы старались.

[@ComodoHacker]

Настоятель рекомендую ознакомится первую часть…
В этой части я отойду от теории к практике, а именно покажу небольшое проект...

Велик и могучи русский языка!

[@ZimM]

Очень странно. Попытался оптимизировать первый попавшийся PNG в режиме Xtreme, получил файл с весом на 41% больше.

[@ZimM]

Поправка: такое только в Interlaced. При Non-interlaced таки получил несколько полегшавшую картинку. С чем может быть связана настолько большая разница между Interlaced и Non-interlaced?

[@kekekeks]

Меняется порядок строк в файле, из-за чего zlib может дать совершенно другую степень сжатия.

[@Lorents]

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

[@proxor]

dimagurov.livejournal.com/49579.html Программа очень старая, но от этого хуже не стала. Это скорее не оптимизация, а выбор наилучшего метода сжатия для достижения минимальных потерь с максимальным сжатием. Результаты подчас неожиданные, но на глаз не отличишь.

[@idart]

Мне кажется, при теперешних каналах интернета проблема долгой загрузки неактуальна. Пользуюсь встроенными утилитами Adobe (Save for web).

[@Lorents]

Хорошо с вами не согласны, большинство компаний, таких как гугол

[@ZiNTeR]

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

Важно понимать: что стоит и что не стоит оптимизировать на сайте. Занятия оптимизаторским онанизмом редко когда приводит к хорошему результату. А в ваших публикациях я нигде не увидел критериев применимости либо неприменимости хотя-бы к каким-то конкретным случаям.

Плюс не забывайте — данные идут пакетами по 512 байт (из них 80 — системная информация). И потому на практике ваши показания в первой части по экономии не верны (я говорю о % — нельзя же по сети переправить половину пакета), а также о том, что экономия в теории на 300 байт далеко не всегда станет экономией на практике (при передаче по сети).

[@chikuyonok]

Плюс не забывайте — данные идут пакетами по 512 байт (из них 80 — системная информация).

Вроде как средний размер пакета 1500 байт. А в целом правильно подметили про опимизаторский онанизм :)

[@404]

Если только вы не делаете версию сайта для мобильных.

[@YaakovTooth]

У меня 32кбит/сек с потерями. Вариантов нет.

[@Gorthauer87]

В случае png это экономия на спичках. Да и чего тут нет такого, что не умеет libpng/libjpeg?

[@Lorents]

если честно, я вообще что Вы имеете ввиду?
libpng используете для сжатия PNG библиотеку zlib, я ее как раз использую
libjpeg я ее тоже использую, JPEGTran основана на libjpeg

[@MadRogue]

Спасибо за утилиту! Просто супер! Помогла ужать графику на 75%