Комментарии 77
Спрячьте, пожалуйста, картинки под кат — не у всех быстрые и безлимитные интернеты.
Средний размер страницы в интернете — порядка 30 Кб.
Размеры картинок в статье — по 50 Кб (мелкие не беру в рассчет).
Итого просмотр картинок обошелся вам в просмотр трех страниц — ну, очень много, чесслово :-)
P.S. А отключать картинки не судьба?
Размеры картинок в статье — по 50 Кб (мелкие не беру в рассчет).
Итого просмотр картинок обошелся вам в просмотр трех страниц — ну, очень много, чесслово :-)
P.S. А отключать картинки не судьба?
В статье про сжатие изображений, фраза про то, что стоит прятать сжатые картинки под кат, вам кажется нормальной?
Надо все-таки подшаманить алгоритм, чтобы картинки снизу вверх подгружались, для небыстрого интернета :)
Средний размер страницы в интернете — порядка 30 Кб.Вы меня сейчас сильно удивили. Это исследование или ваше ощущение, потому что мои ощущения, что эта цифра больше на порядок.
Видимо имелся ввиду желаемый максимум.
Лет 5 назад читал статью art_lomov, в ней он оперировал такими же цифрами, если я сейчас не путаю.
Лет 5 назад читал статью art_lomov, в ней он оперировал такими же цифрами, если я сейчас не путаю.
Не поверите =)
Размер текущей страницы 36 676 байт + 2 картинки в общей сумме 36 676 байт
Похоже человек проверил перед тем как сказать.
Размер текущей страницы 36 676 байт + 2 картинки в общей сумме 36 676 байт
Похоже человек проверил перед тем как сказать.
Я вот, кстати, производил замеры год назад.
Медианный размер страницы, по 200 000 сайтам в рунете: 27 679 символов.
Медианный размер страницы, по 200 000 сайтам в рунете: 27 679 символов.
Я не понял что вы считали. Какие символы? Это был UTF-8? Однобайтовые кодировки? Вы считали объём текста или учитывали полный размер страницы?
Полный объем страницы (со всей разметкой).
Считал в символах, как раз чтобы избежать вопросов с кодировкой. Соответственно, в CP1251 это составило 27,796 байт (с записью отсутствующих символов энтитями), в UTF-8 составило 31,241 байт (поскольку русскоязычные страницы).
Считал в символах, как раз чтобы избежать вопросов с кодировкой. Соответственно, в CP1251 это составило 27,796 байт (с записью отсутствующих символов энтитями), в UTF-8 составило 31,241 байт (поскольку русскоязычные страницы).
Уточню: страница — это размер тела HTTP-ответа. То есть весь HTML (или что там). Без заголовков, но и без запроса и подсчета зависимостей — скриптов, css, картинок.
А, ну так надо полную страницу, а не просто весь текст. Ведь никто не грузит страницу без всех зависимостей, разве нет?
Перечитайте комментарий, с которого вы сами начали эту ветку. Страница отдельно, картинки отдельно. Как бы-то ни было, размер не отличается «на порядок».
Как бы-то ни было, размер не отличается «на порядок».Это вряд ли.
webo.in/articles/habrahabr/43-average-web-page-growth/
«Размер средней веб-страницы увеличился более чем втрое с 2003 года. С 2003 по 2008 годы она увеличилась в размере с 93,7Кб до более 312Кб (см. рисунок 1)».
Если уж сильно хочется, можете добавить медианный размер стилей и ява-скрипта — около 8 Кб.
1) отключи картинки в браузере
2) используй загрузку изображений только из кэша
3) подгружай необходимые изображения по мере надобности
4)…
5) PROFIT!!!
2) используй загрузку изображений только из кэша
3) подгружай необходимые изображения по мере надобности
4)…
5) PROFIT!!!
НЛО прилетело и опубликовало эту надпись здесь
А где же одно из главных отличий сжатия на основе вейвлетов — возможность получать результат постепенно, увеличивая детализацию с приходом новых данных?
А еще где-то я слышал, что гугл этим делом балуется для своих сервисов вроде просмотра пдфов в гдоках, так что может не такое оно уже и непопулярное:)
А еще где-то я слышал, что гугл этим делом балуется для своих сервисов вроде просмотра пдфов в гдоках, так что может не такое оно уже и непопулярное:)
А jpeg 2000 поддерживается браузерами?
А для этого жать результаты преобразования нужно не GZip'ом. Например, как это сделано в EZW или SPIHT кодерах. Gzip тут совсем не в тему.
Не совсем понял при чем тут GZip. Тот же SPIHT как раз на вейвлетах и основан, а гзип — это универсальный алгоритм для всего и вся.
Если сжимать чем-то другим, то пришлось бы в листинг добавить кучу кода. Я же хотел его оставить минимальным.
>А где же одно из главных отличий сжатия на основе вейвлетов — возможность получать результат
>постепенно, увеличивая детализацию с приходом новых данных?
А как progressive jpeg связан с вейвлетами?
>постепенно, увеличивая детализацию с приходом новых данных?
А как progressive jpeg связан с вейвлетами?
А кто сказал, что он связан? Похожий результат не значит одинаковые алгоритмы. Подходы то различные кардинально. Вот Вам ссылочка на статью со сравнением: статья
Ответьте пожалуйста на вопрос, почему в тексте указаны размеры ~7.8, а на самом деле,
Первый 7,8 KБ (7 959 байт)
второй 55 KБ (55 361 байт)
Первый 7,8 KБ (7 959 байт)
второй 55 KБ (55 361 байт)
Вы бы написали что такое вейвлет, немного про Добеши. Задача сжатия картинки вейвлетами Добеши различных степеней у меня была на третьем курсе.
А что такое «быстрый лифтинг дискретного биортогонального CDF 9/7 вейвлета»?
Это особая форма алгоритма подсчёта коэффицентов. Вообще, автору минус, ибо не понятно, к чему эти полукилометровые листинги без объяснения того, что же они делают. Там математика не такая уж и сложная.
Скажите, а есть более подробные статьи по этой теме? Например, код быстрого лифтинга изобилует всяческими a = -1.586134342f; Что это? Почему?
Это коэффиценты из значений функций вейвлет-базиса в определённых точках. А почитать, конечно, есть, даже в общем виде: en.wikipedia.org/wiki/Lifting_scheme
Как раз оно и есть.
Я чуть выше уже отмечал, что общие пояснения мало что объясняют. Меня интересует «подноготная», что за вейвлет-базис, что за функции базиса. Если вы даете ответы, скажите, вы действительно нашли их в материале по той ссылке, которую дали мне?
Ну, я же предполагал, что Вам про вэйвлет-преобразование известно, но не известно про схемы лифтинга. В этой статье на Википедии есть хорошая ссылка «Comprehencive introduction...», где многое объясняется. Но если Вам вообще про вейвлеты надо, то эта тематика так и называется: вейвлет-преобразование. Про него много в интернете. Топикстартеру, конечно, надо бы было хотя бы некие базовые вещи написать.
Жаль, что jpeg2000 так и не поддержали браузеры, очень интересный и удобный формат для изображений, не говоря уже о лучшем визуальном качестве.
На сколько я знаю, его сейчас активно используют в различных ММО играх, где контент создают сами пользователи, например SecondLife. Благодаря возможности постепенно увеличивать детализацию по мере подгрузки, текстуры на объектах появляются почти сразу, и со временем становятся четче.
Правда для реализации «прогрессивной» загрузки поток после вейвлет преобразования организуют особым образом: сначала идут старшие биты низких частот, потом младшие биты низких частот, затем идут более высокие частоты и так далее. На любом этапе загрузку можно остановить и получить законченную картинку с нужной детализацией. То есть можно ограничивать качество загружаемых текстур непосредственно на клиенте, в то время как на сервере будет только один файл.
На сколько я знаю, его сейчас активно используют в различных ММО играх, где контент создают сами пользователи, например SecondLife. Благодаря возможности постепенно увеличивать детализацию по мере подгрузки, текстуры на объектах появляются почти сразу, и со временем становятся четче.
Правда для реализации «прогрессивной» загрузки поток после вейвлет преобразования организуют особым образом: сначала идут старшие биты низких частот, потом младшие биты низких частот, затем идут более высокие частоты и так далее. На любом этапе загрузку можно остановить и получить законченную картинку с нужной детализацией. То есть можно ограничивать качество загружаемых текстур непосредственно на клиенте, в то время как на сервере будет только один файл.
приложите, пожалуйста, рядом с jpeg / jpeg 2000 результаты работы вашего алгоритма. Или результат полностью идентичен jpeg 2000?
Результаты очень схожи.
Хотелось бы увидеть результат, одно дело на словах, совсем другое дело увидеть глазами. Еще не совсем понятно (может я придираюсь), почему изображения к статье сжаты по схеме 5/3 если речь идет о 9/7? Возможно вы использовали кодер основанный на референсном JasPer, он по умолчанию использует для сжатия с потерями и без целочисленное преобразование 5/3, для 9/7 нужно использовать параметр mode=real, правда не все программы использующие эту реализацию кодера позволяют применить дополнительные параметры. Реализация кодера от Kakadu Software, на мой взгляд, лучшая как по скорости, так и по качеству сжатия, этот кодер используется в ACDSee, которая по качеству сжатия заняла первое место в сравнении кодеков JPEG2000 от MSU Graphics & Media Lab.
Я использовал лишь тот листинг на Си, на который есть ссылка в статье.
CDF 5/3 в JPEG2000 используется для безпотерьного сжатия. Для сжатия с потерями в нем используется как раз 9/7
Стандарт не обязывает использовать исключительно 9/7 для сжатия с потерями. Многие кодеры используют 5/3 для сжатия без потерь и с потерями. В частности JasPer по умолчанию использует 5/3 в обоих случаях (о чем я и написал), если не указать явно какое преобразование использовать.
Разница не очень большая, но она есть.
Разница не очень большая, но она есть.
Согласен, просто я имел в виду стандарт JPEG 2000.
The JPEG 2000 compression standard uses the biorthogonal CDF 5/3 wavelet (also called the LeGall 5/3 wavelet) for lossless compression and a CDF 9/7 wavelet for lossy compression.
en.wikipedia.org/wiki/Cohen-Daubechies-Feauveau_wavelet
The JPEG 2000 compression standard uses the biorthogonal CDF 5/3 wavelet (also called the LeGall 5/3 wavelet) for lossless compression and a CDF 9/7 wavelet for lossy compression.
en.wikipedia.org/wiki/Cohen-Daubechies-Feauveau_wavelet
Тоже интересно посмотреть.
А размеры тоже очень похожи?
А размеры тоже очень похожи?
Так я не понял, какой вывод — jpg на сайте можно пережимать или нет?)
Можно, но браузеры не понимают этого формата.
html-страничка с файлом
Раз уже такой случай, разрешите и мне тоже пропиариться:
EPSILON — (Yet Another Wavelet Coder) — epsilon-project.sourceforge.net/
1. Библиотека используется в GIS-движке GDAL:
— www.gaia-gis.it/raster_benchmark/color-ortho-epsilon.html
— www.gdal.org/frmt_epsilon.html
2. Поддерживает ~30 вейвлетных фильтров (в том числе фильтр Добеши 9/7 упомянутый в статье)
3. Работает с изображениями любой формы и любого размера (>>4Gb)
4. Три механизма распараллеливания:
— можно собрать многопоточную версию (POSIX threads)
— можно собрать MPI-версию (протестировано на реальном кластере в МГУ)
— можно собрать кластерную версию (простой TCP-демон)
Также можно собрать обычную однопоточную последовательную версию без наворотов
5. Лицензия LGPL3
6. Есть тесты на Perl для каждого из билдов.
7. Можно заранее указывать желаемую степень сжатия.
8. Есть официальные DEBы для Debain & Ubuntu, есть RPM-ы для шапочек
EPSILON — (Yet Another Wavelet Coder) — epsilon-project.sourceforge.net/
1. Библиотека используется в GIS-движке GDAL:
— www.gaia-gis.it/raster_benchmark/color-ortho-epsilon.html
— www.gdal.org/frmt_epsilon.html
2. Поддерживает ~30 вейвлетных фильтров (в том числе фильтр Добеши 9/7 упомянутый в статье)
3. Работает с изображениями любой формы и любого размера (>>4Gb)
4. Три механизма распараллеливания:
— можно собрать многопоточную версию (POSIX threads)
— можно собрать MPI-версию (протестировано на реальном кластере в МГУ)
— можно собрать кластерную версию (простой TCP-демон)
Также можно собрать обычную однопоточную последовательную версию без наворотов
5. Лицензия LGPL3
6. Есть тесты на Perl для каждого из билдов.
7. Можно заранее указывать желаемую степень сжатия.
8. Есть официальные DEBы для Debain & Ubuntu, есть RPM-ы для шапочек
Жму руку! У вас есть все. Интересно будет поковырять сырцы.
Если кому интересно, то есть LGPL библиотека для вейвлетного сжатия (не в JPEG2000):
www.libpgf.org
Свой код можно не открывать, если указали в About, что используете PGF.
www.libpgf.org
Свой код можно не открывать, если указали в About, что используете PGF.
А можно поинтересоваться — каков смысл данной статьи? «Вейвлеты для самых маленьких»?
Про теорию не рассказано, нормального сравнения с другими алгоритмами нет.
ИМХО данную статью можно на code.google.com постить, а не на хабр.
Про теорию не рассказано, нормального сравнения с другими алгоритмами нет.
ИМХО данную статью можно на code.google.com постить, а не на хабр.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сжатие изображений с использованием вейвлет