Comments 31
Сомневаюсь, что подобное будет использоваться в ближайшее время. Может лет через 5 но вряд ли.
Скорость загрузки меня разочаровала.
Скорость загрузки меня разочаровала.
Я честно признал, что не выполнил сжатие коэффициентов. После сжатия, объем подгружаемой информации был бы очень маленький. Проблемы с объемом трафика у этой технологии нет, точно. Но вот разархивирование поступающей информации, вместе с вейвлет преобразованием может сильно повесить браузер. Надо пробовать. Думаю пятилетняя оценка завышена, работоспособные аналоги на Flash давно существуют.
На картинку 1024х1024 подгружается более 3Мб коэффициентов. Почему бы просто не конвертировать JPEG с прогрессивной загрузкой?
Вот пример изображения с прогрессивной 5 этапной загрузкой img42.imageshack.us/img42/5172/910334752x3168p.jpg
Вот пример изображения с прогрессивной 5 этапной загрузкой img42.imageshack.us/img42/5172/910334752x3168p.jpg
на имадж хостингах картинки если загружаешь прогрессивный jpg конвертирует в обычный
Я за JPEG с прогрессивной загрузкой, а так же за уже существующий jp2, который еще лучше. Своим примером я хотел показать, что с HTML5 мы получили возможность реализовать свой или чужой (в алгоритмическом смысле) готовый jpeg на вейвлетах не дожидаясь браузеров. У нас так же появляется возможно создавать доступ к фрагменту изображения который нас интересует. Кликаем на интересующий нас фрагмент и дальше грузиться только он (может быть интересно для картографии). Намертво вшитый в браузер алгоритм jpeg2000 или прогрессивный jpeg нас может не устроить.
То что вам нужно — так это алгоритм иерархической компрессии изображений. Более того — к картам глупо подходить так же как и к изображениям реального мира — у растровых карт есть множество особенностей которые можно учесть при кодировании. Вам, например, сюда: Метод иерархической компрессии индексных изображений. В конце концов для отображении карты замечательно подойдет png с индексированной палитрой.
Спасибо за материал. Отмечу, что вейвлет-преобразование иерархическое само по себе. И сжимают его часто нуль-деревьями, которые очень хорошо учитывают иерархичность структуры. Но признаю, от проблем картографии я далек, мой комментарий выше был лишь интуитивным соображением. Если сжимать карты и делать доступ по области интереса не хорошо через вейвлеты, то остаются классические изображения девушек(например lena, кто ее знает по статьям о сжатие изображений).
Честно говоря, не понял назначения статьи:
— описания вейвлетов толком нет (отсылка на название книжки не считается);
— пример объясняется только на словах; ни в архиве с C#, ни в примере на JS дофига кода почти без комментариев;
— итоговая работа примера не показывает преимуществ;
— нигде не сказано, что само по себе DWT не сжимает данных в явном виде (эвристики с отбрасыванием ветвей разложения не учитываем), а предложение пожать текстовые файлики Хаффманом — это не о том.
— описания вейвлетов толком нет (отсылка на название книжки не считается);
— пример объясняется только на словах; ни в архиве с C#, ни в примере на JS дофига кода почти без комментариев;
— итоговая работа примера не показывает преимуществ;
— нигде не сказано, что само по себе DWT не сжимает данных в явном виде (эвристики с отбрасыванием ветвей разложения не учитываем), а предложение пожать текстовые файлики Хаффманом — это не о том.
Ваш комментарий справедлив по всем пунктам, но не в целом. Статься должна заинтересовавшихся подтолкнуть узнать, что такое вейвлет и как с ними работать. Напомнить, что появилась возможность рисовать в браузере. Студентам, которым нужны вейвлеты, предоставить код. Он без комментариев, но легкой жизни ни кто не обещал. Возможно, показать идею необычной визуализации изображений.
>>Статься должна заинтересовавшихся подтолкнуть узнать, что такое вейвлет и как с ними работать.
Почему? Итоговый пример не показывает преимуществ.
>>Напомнить, что появилась возможность рисовать в браузере.
Поиск по Хабру выдает 470 топиков про canvas, не считая отдельного хаба. Об этот тут очень часто говорят.
>>Студентам, которым нужны вейвлеты, предоставить код.
Честно говоря, лучше почитать книжки типа «Методы сжатия данных» за авторством Ватолина, Ратушняка, Смирнова, Юкина. Объем кода примера не располагает к его изучению без знания теории того, как DWT вообще работает.
Вам, на мой взгляд, хорошо бы было раскрыть хотя бы одну из этих тем: или теория вейвлетов, или работа с ними в C#, или отрисовка обратного преобразования с выводом на канве.
А так всего понемногу, а в целом ничего не понятно.
Почему? Итоговый пример не показывает преимуществ.
>>Напомнить, что появилась возможность рисовать в браузере.
Поиск по Хабру выдает 470 топиков про canvas, не считая отдельного хаба. Об этот тут очень часто говорят.
>>Студентам, которым нужны вейвлеты, предоставить код.
Честно говоря, лучше почитать книжки типа «Методы сжатия данных» за авторством Ватолина, Ратушняка, Смирнова, Юкина. Объем кода примера не располагает к его изучению без знания теории того, как DWT вообще работает.
Вам, на мой взгляд, хорошо бы было раскрыть хотя бы одну из этих тем: или теория вейвлетов, или работа с ними в C#, или отрисовка обратного преобразования с выводом на канве.
А так всего понемногу, а в целом ничего не понятно.
Все справедливо. Если будут еще комментарии или сообщения на почту подобного рода, то будет узкоспециализированная статья. Лично Вам, какое либо из перечисленных направлений интересно?
Если вы хорошо разобрались в предмете — напишите серию статей: от общей теории DWT (можно даже вскользь про непрерывное вейвлет преобразование) до вывода на канву. Все по шагам, с описанием и примерами. Вот это будет отлично и полезно!
Я сам больше занимался iDWT без потерь и предобработкой и дожатием результатов (BWT, MTF, RC). Так что просто почитаю.
Я сам больше занимался iDWT без потерь и предобработкой и дожатием результатов (BWT, MTF, RC). Так что просто почитаю.
Из своих ковыряний вейвлетов вынес одно — сделать так, чтобы качество изображения пожатого вейвлетами было хотя-бы таким же, как и у аккуратно пожатого JPEG при одинаковом битрейте — крайне сложно.
Очень уж удачная штука, этот JPEG.
Очень уж удачная штука, этот JPEG.
реализовать можно все, что угодно. Хоть перекодирование на JS изображения из BMP в JPEG. Только зачем? Через 5 лет (то время, когда процессоры/браузеры смогут адекватно рендерить динамический canvas заявленных объемов) необходимость в прогрессивном JPEG отпадет: проходимость каналов станет лучше. Да и предзагрузка изображений сейчас решает все эти проблемы (остается только проблема первой загрузки незакэшированного сайта, но здесь пользователи уже привыкли ждать красивые картинки, для мобильных версий можно и графику попроще использовать).
Это я к чему: прикладного смысла в описанных действиях мало.
Это я к чему: прикладного смысла в описанных действиях мало.
Точку в поднятой теме можно поставить, только написав качественную реализацию на уровне jpeg2000 и выложить в свободное пользование. Если ни кого не заинтересует значит так тому и быть. Прикладного смысла в тысячах статей про сжатия вообще мало, учитывая, что купить жесткий диск на терабайт легко, а увеличить эффективность сжатия процентов на 10% очень трудно. Статьи про прогрессивную загрузку изображений теряют свою актуальность с увеличением скоростей передачи данных, но в данный момент еще актуальны, немного.
Одной из особенностей jpeg200 была возможность грузить изображения с любым разрешением и качеством из одного и того же файла. То есть для мобильных браузеров не надо было бы делать свои изображения, а только ограничивать какую часть файла грузить. Теоретически это может быть удобно.
Удобно с какой стороны? Сервер ведь не знает, какую часть файла отдавать для мобильного устройства — это устройство знает, какая часть из гигантского файла предназначена ей. Это на уровне серверных правил решается, а не на уровне форматов изображений.
В общем это можно реализовать через Range или псевдостриминг FLV (?start=xxx): отсылать на сервер запрос нужного интервала в файле. Сначала получили заголовки, прикинули где нужный нам кусок и запросили только его.
Да нет, файл передаётся последовательно с самого начала, пока клиент не скажет «всё, мне хватит и так уже хорошая картинка». В этом и суть прогрессивной загрузки.
Функциональность по управлению загрузкой несомненно может быть полезна, но не является прогрессивной загрузкой в первоначальном смысле (в прогрессивном jpeg нет отдельной функции прервать получение данных). Основная задача — дать максимально полное представление об изображение из уже полученных данных.
> сносно переносят трудоемкие математические вычисления (с современным компьютером).
web workers вам в руки
web workers вам в руки
Огромное спасибо, прочитал о нем. Жалко, Explorer как всегда не торопиться поддерживать полезные новшества. Еще очень не хватает функции, которая возвращает количество ядер.
Насчёт IE особо не беспокойтесь. Девятая версия вполне поддерживает web workers, а предыдущие (8 / 7 / 6) сейчас очень мало распространены. В любом случае есть специальные обёртки, которые эмулируют workers — многозадачности, разумеется, нет, но код переписывать заново не приходится.
Насчёт ядер гляньте поподробнее useragent. Может что-то найдёте.
В любом случае там есть битность (32 / 64 / 32-приложение в 64).
В любом случае там есть битность (32 / 64 / 32-приложение в 64).
Sign up to leave a comment.
Реализации прогрессивной загрузки изображений