1. Тут кстати вопрос в быстром алгоритме вычисления регионов;
2. Если каналы разделить и расположить друг за другом, то сжатие будет хуже. Проверял уже;
3. вот про это я не совсем понимаю вашу мысль. 6 шаг хоть и выглядит растратным — но таковым не является ни по времени, ни по результатам влияния на выходной поток;
4. в lossless режиме вообще нельзя менять палитру на YCrCb. Один в один уже не восстановится;
5. Ок, прогоню на этом наборе.
1. Выключение предусмотрено. Я делаю применяю фильтр для всех строк, т.е. сразу на все изображения;
2. Тут конечно надо тестить, но скорее всего достаточно будет внести коррективы в первые 2 этапа алгоритма;
3. Так ведь после BWT как раз образуются цепочки одинаковых символов;
4. В этом случае появится елезаметное размытие цвета толщиной в 1 пиксель вокруг выдающихся из общего фона одиночных пикселей, а это уже имхо серьезная потеря качества. 2х2 квантование можно при желании добавить в спецификацию. Собственно это уже есть в тестовой программе, только выключено. Думаю надо перекомпилировать тестовую программу добавив доступ к скрытым опциям;
5. Я тогда взял случайным образом штук 10-15 файлов; Вообще конечно стоит скачать все 300 с лишним картинок и прогнать тест для алгоритма по ним всем.
1. да, побайтно. Естественно с разделением по цветовым каналам. Сразу скажу, что этот фильтр чаще всего дает очень большой выигрыш;
2. Альфа в текущем формате предусмотрена, но не реализована. Имхо это можно реализовать, если формат кто нибудь захочет использовать по назначению;
3. Тут скорее всего вы с чем-то путаете BWT, он лишь переставляет байты во входном потоке, но не сжимает его;
4. Вы про квантование цветовых Cr и Cb компонент?
5. Эти файлы я как раз таки взял из набора тестовых изображений, вот часть из них.
Я не воспринимаю это как наезд, просто лично мне тема интересна, рад, что есть единомышленники. Я не претендую на первое место во всех конкурсах и не говорю, что PNG фигня. 5 лет назад я писал на VB, в принципе много чего инетересного на нем понаделал в том числе и HTML рендер и движок БД и игрушки, убедиться в этом можно почитав мой профиль на форуме.
Попробовал сжать при помощи zlib.dll размер файла получился 175 457 байт. В режиме lossy — 139 059.
В принципе можете сами попробовать сжать посжимать различными архиваторами. Вот сырой файл без 7-го этапа.
Результаты сравнения BWT реализации Дмитрия Малышева с другими реализациями можно посмотреть на специальной странице. Также можно почитать описание самой реализации.
Пункты 5,6 и 7 работают как универсальный алгоритм сжатия.
По поводу 6-го пункта (экспериментально подобранного количества проходов). Это число я подобрал по результатам теста на группе файлов
из 15 различных по характеру изображений.
Количество проходов не связано с количеством каналов RGB. Да, количество прогонов можно варьировать вплоть до 0.
На каждом прогоне если к примеру взять тестовое изображение, замерить выходной поток после 5-го этапа: 567 613 байт,
поток после каждого прогона 6 этапа уменьшается до:
454 497
354 575
302 011
Если добавить к примеру еще 2 прогона, то выигрыш теряется и будут такие результаты:
309 825
305 539
Если 6-й этап совсем исключить из цепочки, то тестовый файл сжался бы на 2кб хуже и весил бы 157 317 байт.
Битовая карта растет линейно с размерами изображения.
Я как-то писал свой беспотерьный компрессор полноцветных изображений.
По большинству тестов он значительно выигрывает у PNG.
В данном случае приведенную для тестов картинку размером 184 320 байт мой компрессор сжимает до 86 791 байт за 0,26 сек. Тут правда стоит учесть, что реализация на VisualBasic.
И не стоит забывать, что у меня совсем без потерь. Т.е. изображение восстанавливается с точностью до бита.
В статье говорится, что «группа частных азиатских инвесторов выкупила эксклюзивные права на продвижение в Азии», но никак не «ученые продали идею в Азию».
Совершенно ясно, что это разные вещи.
4. Поток коррекции это конечно интересно. Обязательно попробую.
2. Если каналы разделить и расположить друг за другом, то сжатие будет хуже. Проверял уже;
3. вот про это я не совсем понимаю вашу мысль. 6 шаг хоть и выглядит растратным — но таковым не является ни по времени, ни по результатам влияния на выходной поток;
4. в lossless режиме вообще нельзя менять палитру на YCrCb. Один в один уже не восстановится;
5. Ок, прогоню на этом наборе.
2. Тут конечно надо тестить, но скорее всего достаточно будет внести коррективы в первые 2 этапа алгоритма;
3. Так ведь после BWT как раз образуются цепочки одинаковых символов;
4. В этом случае появится елезаметное размытие цвета толщиной в 1 пиксель вокруг выдающихся из общего фона одиночных пикселей, а это уже имхо серьезная потеря качества. 2х2 квантование можно при желании добавить в спецификацию. Собственно это уже есть в тестовой программе, только выключено. Думаю надо перекомпилировать тестовую программу добавив доступ к скрытым опциям;
5. Я тогда взял случайным образом штук 10-15 файлов; Вообще конечно стоит скачать все 300 с лишним картинок и прогнать тест для алгоритма по ним всем.
2. Альфа в текущем формате предусмотрена, но не реализована. Имхо это можно реализовать, если формат кто нибудь захочет использовать по назначению;
3. Тут скорее всего вы с чем-то путаете BWT, он лишь переставляет байты во входном потоке, но не сжимает его;
4. Вы про квантование цветовых Cr и Cb компонент?
5. Эти файлы я как раз таки взял из набора тестовых изображений, вот часть из них.
Я не воспринимаю это как наезд, просто лично мне тема интересна, рад, что есть единомышленники. Я не претендую на первое место во всех конкурсах и не говорю, что PNG фигня. 5 лет назад я писал на VB, в принципе много чего инетересного на нем понаделал в том числе и HTML рендер и движок БД и игрушки, убедиться в этом можно почитав мой профиль на форуме.
В принципе можете сами попробовать сжать посжимать различными архиваторами. Вот сырой файл без 7-го этапа.
По поводу 6-го пункта (экспериментально подобранного количества проходов). Это число я подобрал по результатам теста на группе файлов
из 15 различных по характеру изображений.
Количество проходов не связано с количеством каналов RGB. Да, количество прогонов можно варьировать вплоть до 0.
На каждом прогоне если к примеру взять тестовое изображение, замерить выходной поток после 5-го этапа: 567 613 байт,
поток после каждого прогона 6 этапа уменьшается до:
- 454 497
- 354 575
- 302 011
Если добавить к примеру еще 2 прогона, то выигрыш теряется и будут такие результаты:- 309 825
- 305 539
Если 6-й этап совсем исключить из цепочки, то тестовый файл сжался бы на 2кб хуже и весил бы 157 317 байт.Битовая карта растет линейно с размерами изображения.
По большинству тестов он значительно выигрывает у PNG.
В данном случае приведенную для тестов картинку размером 184 320 байт мой компрессор сжимает до 86 791 байт за 0,26 сек. Тут правда стоит учесть, что реализация на VisualBasic.
И не стоит забывать, что у меня совсем без потерь. Т.е. изображение восстанавливается с точностью до бита.
Совершенно ясно, что это разные вещи.
7monetok.com/
и это кстати не мешает ему быть сверстанным на таблицах =)
Поэтому никаких алгоритмов избежания столкновений нет.
{
$f=$i%3?'':'Fizz';
$b=$i%5?'':'Buzz';
echo$f.$b?$f.$b:$i,',';
}