Rst7 5 2 июня, 2008 Опубликовано 2 июня, 2008 · Жалоба Так я же уточнил, что цвет 4:2:2, а не 4:2:0, так что 4+2+2=8.На BF'е, как я уже говорил, 5 MI. Немного поплясал с бубном, вспомнив, что среди результатов квантизации почти 75% нулей (это для всех картинок, так сама идея кодера задумана), следовательно, можно неплохо выиграть, правильно написав условия (т.е. обеспечить кратчайшее время при 0). После этого на моей тестовой картинке 3235931 такта. Больше видимо уже не удасться выжать. Кстати, бекпорт оптимизированного кодера привел к результату 8561325 на AVR (было около 12 миллионов). И вот еще что - отношение количества тактов на AVR к ARM можно рассматривать как ориентировочную цифру увеличения производительности чисто за счет разрядности - 2.6 раза (при одинаковых тактовых, конечно). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 26 2 июня, 2008 Опубликовано 2 июня, 2008 · Жалоба После этого на моей тестовой картинке 3235931 такта. Больше видимо уже не удасться выжать. Вот видите, можете поблагодарить меня за предоставленный стимул.. :beer: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 2 июня, 2008 Опубликовано 2 июня, 2008 · Жалоба Вот видите, можете поблагодарить меня за предоставленный стимул.. Спасибо. Кстати, получается, что разрыв с BF сократили до 30%. Я считаю - есть над чем подумать... (не нам с Вами, а тем, кто сейчас чешет репу с вопросом "какую бы каменюку мне в проект заложить";) ) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 26 2 июня, 2008 Опубликовано 2 июня, 2008 · Жалоба Я считаю - есть над чем подумать... Подумать всегда есть над чем, но нужно не забывать, что конвейер в BF - 10 тактов, а рабочая частота ядра - 600 МГц. ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
etoja 0 3 июня, 2008 Опубликовано 3 июня, 2008 · Жалоба Для быстрого сжатия можно использовать: 1) алгоритм JPEG-LS, в котором нет дискретного косинусного преобразования (смотри приложение) 2) аппаратное сжатие. У Xilinx есть свободно распространяемый пример сжатия со скоростью 24 кадра в секунду. ljpg.zip Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 26 3 июня, 2008 Опубликовано 3 июня, 2008 · Жалоба Для быстрого сжатия можно использовать: 1) алгоритм JPEG-LS, в котором нет дискретного косинусного преобразования (смотри приложение) 2) аппаратное сжатие. У Xilinx есть свободно распространяемый пример сжатия со скоростью 24 кадра в секунду. 1) насколько мне известно, алгоритм JPEG-LS жмет в 3-4 раза, что, IMHO, недостаточно для многих приложений. 2) А что за кадры? Размер кадра? Цвет? И сколько стоит реализация на FPGA? Есть оценки? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 3 июня, 2008 Опубликовано 3 июня, 2008 · Жалоба 1) алгоритм JPEG-LS, в котором нет дискретного косинусного преобразования (смотри приложение) Вы думаете, что DCT - это самое зло? Вы ошибаетесь. Обработка результатов DCT занимает столько же времени, что и само преобразование (хотя бы потому, что необходимо каждую гармонику (а их всего столько же, сколько пикселей) разделить на коэффициент) - причем, это с учетом всех оптимизаций (деление заменено на умножение на 1/q; если делимое меньше делителя, сразу исполняется быстрая обработка нулевого результата). А вот в LS надо над каждым пикселем поплясать немало. Ну и часто необходим больший коэффициент сжатия. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 3 июня, 2008 Опубликовано 3 июня, 2008 · Жалоба И вот еще что - отношение количества тактов на AVR к ARM можно рассматривать как ориентировочную цифру увеличения производительности чисто за счет разрядности - 2.6 раза (при одинаковых тактовых, конечно). Очень интересное число. Для общего развития не можете назвать получившееся при этом соотношение размеров кода? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
etoja 0 3 июня, 2008 Опубликовано 3 июня, 2008 · Жалоба Если вместо DCT применить преобразование Уолша (Walsh transform), то кадровая скорость сжатия возрастёт в 4 раза. Правда это будет нестандартный JPEG. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 3 июня, 2008 Опубликовано 3 июня, 2008 · Жалоба Для общего развития не можете назвать получившееся при этом соотношение размеров кода? 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 26 3 июня, 2008 Опубликовано 3 июня, 2008 (изменено) · Жалоба Если вместо DCT применить преобразование Уолша (Walsh transform), то кадровая скорость сжатия возрастёт в 4 раза. Правда это будет нестандартный JPEG. Для BF по моим оценкам, затраты на DCT -15%, а на сжатие Huffman'ом и все остальное - 85%. Где тут можно получить выигрыш в 4 раза? Изменено 3 июня, 2008 пользователем blackfin Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 3 июня, 2008 Опубликовано 3 июня, 2008 · Жалоба По моим оценкам, затраты на DCT -25%, а на сжатие Huffman'ом - 75%. Это на BF. Там DCT конечно лучше должно получиться, все-таки несколько MAC за такт. А на AVR/ARM/AVR32 соотношение 50 на 50. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
etoja 0 3 июня, 2008 Опубликовано 3 июня, 2008 · Жалоба DCT и преобразование Уолша проверены на реальном продаваемом оборудовании http://telekadr.by.ru Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 3 июня, 2008 Опубликовано 3 июня, 2008 · Жалоба 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 3 июня, 2008 Опубликовано 3 июня, 2008 · Жалоба Гм... Вообщем, нельзя доверять этим симуляторам в иаре... AVR'овский правильно такты считает, а ARM - слишком льстит - B за 1 такт вместо 3, ST за 1 такт вместо 2, LD за 2 такта вместо 3х.. AVR32 тоже далек от правды, причем в другую сторону... Ну для AVR32 я студию выйму, посмотрю, чего она насчитает, а вот для ARM'а... Чем бы таким посимулить поумнее? DCT и преобразование Уолша проверены на реальном продаваемом оборудовании Это говорит только о том, что Вы не в теме ;) И оптимизацию, как сейчас модно говорить, ниасилили. Очень интересное число. Щас будем пересматривать... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться