[Rst7 5]

Так я же уточнил, что цвет 4:2:2, а не 4:2:0, так что 4+2+2=8.На BF'е, как я уже говорил, 5 MI.

 

Немного поплясал с бубном, вспомнив, что среди результатов квантизации почти 75% нулей (это для всех картинок, так сама идея кодера задумана), следовательно, можно неплохо выиграть, правильно написав условия (т.е. обеспечить кратчайшее время при 0). После этого на моей тестовой картинке 3235931 такта. Больше видимо уже не удасться выжать.

 

Кстати, бекпорт оптимизированного кодера привел к результату 8561325 на AVR (было около 12 миллионов).

 

И вот еще что - отношение количества тактов на AVR к ARM можно рассматривать как ориентировочную цифру увеличения производительности чисто за счет разрядности - 2.6 раза (при одинаковых тактовых, конечно).

[blackfin 23]

После этого на моей тестовой картинке 3235931 такта. Больше видимо уже не удасться выжать.

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

[Rst7 5]

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

 

Спасибо. Кстати, получается, что разрыв с BF сократили до 30%. Я считаю - есть над чем подумать... (не нам с Вами, а тем, кто сейчас чешет репу с вопросом "какую бы каменюку мне в проект заложить";) )

[blackfin 23]

Я считаю - есть над чем подумать...

Подумать всегда есть над чем, но нужно не забывать, что конвейер в BF - 10 тактов, а рабочая частота ядра - 600 МГц. ;)

[etoja 0]

Для быстрого сжатия можно использовать:

1) алгоритм JPEG-LS, в котором нет дискретного косинусного преобразования (смотри приложение)

2) аппаратное сжатие. У Xilinx есть свободно распространяемый пример сжатия со скоростью 24 кадра в секунду.

ljpg.zip

[blackfin 23]

Для быстрого сжатия можно использовать:

1) алгоритм JPEG-LS, в котором нет дискретного косинусного преобразования (смотри приложение)

2) аппаратное сжатие. У Xilinx есть свободно распространяемый пример сжатия со скоростью 24 кадра в секунду.

1) насколько мне известно, алгоритм JPEG-LS жмет в 3-4 раза, что, IMHO, недостаточно для многих приложений.

2) А что за кадры? Размер кадра? Цвет?

И сколько стоит реализация на FPGA? Есть оценки?

[Rst7 5]

1) алгоритм JPEG-LS, в котором нет дискретного косинусного преобразования (смотри приложение)

 

Вы думаете, что DCT - это самое зло? Вы ошибаетесь. Обработка результатов DCT занимает столько же времени, что и само преобразование (хотя бы потому, что необходимо каждую гармонику (а их всего столько же, сколько пикселей) разделить на коэффициент) - причем, это с учетом всех оптимизаций (деление заменено на умножение на 1/q; если делимое меньше делителя, сразу исполняется быстрая обработка нулевого результата). А вот в LS надо над каждым пикселем поплясать немало.

 

Ну и часто необходим больший коэффициент сжатия.

[zltigo 1]

И вот еще что - отношение количества тактов на AVR к ARM можно рассматривать как ориентировочную цифру увеличения производительности чисто за счет разрядности - 2.6 раза (при одинаковых тактовых, конечно).

Очень интересное число. Для общего развития не можете назвать получившееся при этом соотношение размеров кода?

[etoja 0]

Если вместо DCT применить преобразование Уолша (Walsh transform), то кадровая скорость сжатия возрастёт в 4 раза. Правда это будет нестандартный JPEG.

[Rst7 5]

Для общего развития не можете назвать получившееся при этом соотношение размеров кода?

 

ARM: 2 232 bytes in segment CODE

AVR: 2 026 bytes in segment CODE

AVR32: 1 910 bytes in segment CODE32

 

ARM в арме. Тумбу даже пробовать не буду, регистров не хватит, будет дупа по производительности.

 

Если вместо DCT применить преобразование Уолша (Walsh transform), то кадровая скорость сжатия возрастёт в 4 раза. Правда это будет нестандартный JPEG.

 

Вы читаете то, что я пишу? Если выбросить DCT, то времени займет только в 2 раза меньше

 

Конечно, если у Вас плохо дело с оптимизацией самого DCT - тогда да.

[blackfin 23]

Если вместо DCT применить преобразование Уолша (Walsh transform), то кадровая скорость сжатия возрастёт в 4 раза. Правда это будет нестандартный JPEG.

Для BF по моим оценкам, затраты на DCT -15%, а на сжатие Huffman'ом и все остальное - 85%.

Где тут можно получить выигрыш в 4 раза?

Изменено 3 июня, 2008 пользователем blackfin

[Rst7 5]

По моим оценкам, затраты на DCT -25%, а на сжатие Huffman'ом - 75%.

 

Это на BF. Там DCT конечно лучше должно получиться, все-таки несколько MAC за такт.

 

А на AVR/ARM/AVR32 соотношение 50 на 50.

[etoja 0]

DCT и преобразование Уолша проверены на реальном продаваемом оборудовании

http://telekadr.by.ru

[zltigo 1]

ARM: 2 232 bytes in segment CODE

AVR: 2 026 bytes in segment CODE

AVR32: 1 910 bytes in segment CODE32

Совершенно привычные соотношения. Cпасибо.

ARM в арме. Тумбу даже пробовать не буду...

Это правильно :)

[Rst7 5]

Гм... Вообщем, нельзя доверять этим симуляторам в иаре... AVR'овский правильно такты считает, а ARM - слишком льстит - B за 1 такт вместо 3, ST за 1 такт вместо 2, LD за 2 такта вместо 3х.. AVR32 тоже далек от правды, причем в другую сторону... Ну для AVR32 я студию выйму, посмотрю, чего она насчитает, а вот для ARM'а... Чем бы таким посимулить поумнее?

 

DCT и преобразование Уолша проверены на реальном продаваемом оборудовании

 

Это говорит только о том, что Вы не в теме ;) И оптимизацию, как сейчас модно говорить, ниасилили.

 

Очень интересное число.

 

Щас будем пересматривать...