| |
|
  |
 Алгоритм JPEG, JPEG |
|
|
|
|
 Jul 17 2009, 11:47
|
Частый гость
Группа: Участник
Сообщений: 132
Регистрация: 11-07-08
Пользователь №: 38 870
|
// Вы. На этом форуме ценят корректность. Вы извините меня... //Непонятный подсчет. Откуда 83 мкс? За время 40мс (25 кадров в секунду) надо обработать 4800 квадратов ч/б плюс 2*1200 квадратов для цвета. А если буфер только на 8 строк, то обработку можно начинать только после 16 байт 8-й строки и заканчивать после 16 байт 1 строки следующего буфера. То есть за время ввода одной строки надо обработать 80 квадратов 8х8. Длина одной строки 640*2(байта). Время ввода одной строки 40мс/(640*480*2) *1280 =83,3мкс Вроде так? //В 51ом камне там только бизнеслогика. Остальное - аппаратные ускорители. Возможно... Но не факт. Частота внутри 48МГц и однотактовый. Может быть и хватает для 9fps. Да и стоил бы такой камень дороговато. Вон тут из китая привезли камень -- 51-й однотактовый(не все команды). На 24МГц летает похлеще AVRки. Только архитектура полностью не раскрыта. //Считайте сами. При сжатии 1:10 расход на ARM7 примерно 55 тактов на точку (для ч/б, для цветного - примерно 80). Судя по приведенным цифрам, хватает даже на цветность... Но ведь где-то грабли лежат наверняка... Цитата(DRUID3 @ Jul 17 2009, 14:56)  А кто-нить, что-нить писАл для JPEG2000? Меня интересует вменяемое описание(желательно на русском) - ибо исходники для BSD/Linux найти не проблема, но надо же еще и понимать о чем речь...
P.S.: а вообще есть такое понятие как mJPEG2000? Уж больно хорошо жмется(на порядок лучше JPEG) - находка для всяких охранных систем... А мне и JPEGa хватит...
|
|
|
|
|
|
|
|
Jul 17 2009, 11:56
|
Йа моск ;)
Группа: Модераторы
Сообщений: 4 345
Регистрация: 7-07-05
Из: Kharkiv-city
Пользователь №: 6 610
|
Цитата Возможно... Но не факт. Частота внутри 48МГц и однотактовый. Может быть и хватает для 9fps. Для 51го - не хватит. Цитата Судя по приведенным цифрам, хватает даже на цветность... Но ведь где-то грабли лежат наверняка... По каким цифрам? Кому хватает?
--------------------
"Практика выше (теоретического) познания, ибо она имеет не только достоинство всеобщности, но и непосредственной действительности." - В.И. Ленин
|
|
|
|
|
|
|
|
Jul 17 2009, 12:03
|
Частый гость
Группа: Участник
Сообщений: 132
Регистрация: 11-07-08
Пользователь №: 38 870
|
Цитата(Rst7 @ Jul 17 2009, 15:56) По каким цифрам? Кому хватает? Вы только что привели 80 тактов на точку для АРМ7. 640*480*80=24576000 тактов. Или Вы имели ввиду какие-то другие такты?
|
|
|
|
|
|
|
|
Jul 17 2009, 12:13
|
Йа моск ;)
Группа: Модераторы
Сообщений: 4 345
Регистрация: 7-07-05
Из: Kharkiv-city
Пользователь №: 6 610
|
Цитата Вы только что привели Привел. Имеем 25 миллионов тактов на кадр. При тактовой 100МГц имеем 4 кадра в секунду. Цитата Спасибо, но то, только для избранных А тут (сайт тот же  ) - http://www.jpeg.org/public/fcd15444-1.pdf
--------------------
"Практика выше (теоретического) познания, ибо она имеет не только достоинство всеобщности, но и непосредственной действительности." - В.И. Ленин
|
|
|
|
|
|
|
|
Jul 17 2009, 12:18
|
Частый гость
Группа: Участник
Сообщений: 132
Регистрация: 11-07-08
Пользователь №: 38 870
|
Цитата(Rst7 @ Jul 17 2009, 16:06) Привел. Имеем 25 миллионов тактов на кадр. При тактовой 100МГц имеем 4 кадра в секунду. Если принять за истину эти 80 тактов на точку... Тогда АРМ9 надо. Есть, правда ,небольшие лазейки... Если запускать программу кодер в памяти АРМ7 скорость несомненно возрастет в разы, верно? Плюс к этому если данные уже приходят в формате YUV4:2:2 or 4:2:0 , а не преобразовываются из RGB ? Ну и еще -- если все таки использовать 320 на 240 Что Вы об этом думаете?
Сообщение отредактировал Step_ARM - Jul 17 2009, 12:25
|
|
|
|
|
|
|
|
Jul 17 2009, 12:34
|
Частый гость
Группа: Участник
Сообщений: 132
Регистрация: 11-07-08
Пользователь №: 38 870
|
Цитата(Rst7 @ Jul 17 2009, 16:24) Их нет. Данные по тактам - для выполнения из ОЗУ. И никакого матрицирования нет (т.е. уже YUV на входе). Жаль... Только если скатиться 320х240(11-12 кадров/сек) или использовать CortexM3 LPC17XX 352x288. Спасибо дорогому товарищу Rst7...
|
|
|
|
|
|
|
|
Jul 20 2009, 03:56
|
Частый гость
Группа: Участник
Сообщений: 132
Регистрация: 11-07-08
Пользователь №: 38 870
|
Цитата(Rst7 @ Jul 19 2009, 09:12) Число все-же ближе к 1.5. 80 тактов на точку - это умноженное на 1.5 число тактов для ЧБ. Реально - немного лучше. Но на фоне того, что BF имеет под полгигагерца тактовую - это все меркнет (даже то, что BF как ракета вычисляет DCT и здорово тупит над Хаффманом). Нашел упоминание о быстром алгоритме вычисления DCT -- заранее вычисляется некая матрица и в момент преобразования умножается на NxN матрицу. Вроде как быстрее намного...
|
|
|
|
|
|
|
|
Jul 20 2009, 07:29
|
Частый гость
Группа: Участник
Сообщений: 132
Регистрация: 11-07-08
Пользователь №: 38 870
|
Цитата(Rst7 @ Jul 20 2009, 09:30) Ссылку в студию. Хотя, я лично очень сомневаюсь. http://articles.org.ru/docum/jpeg.php
Прикрепленные изображения
|
|
|
|
|
|
|
|
Jul 20 2009, 07:42
|
Йа моск ;)
Группа: Модераторы
Сообщений: 4 345
Регистрация: 7-07-05
Из: Kharkiv-city
Пользователь №: 6 610
|
Цитата Пейсатели блин... Цитата При перемножении матриц “цена” вычисления одного элемента результирующей матрицы составляют N умножений и N сложений, при вычислении матрицы дискретного косинусного преобразования - 2xN соответственно. По сравнению с O(NxN) это заметное повышение производительности. Так как дискретное косинусное преобразование является разновидностью преобразования Фурье, то все методы ускорения преобразования Фурье могут быть применены и в данном случае. Набор слов. Не читайте перед обедом советских газет (ЦЭ). Цитата * A 2-D DCT can be done by 1-D DCT on each row followed by 1-D DCT
* on each column. Direct algorithms are also available, but they are
* much more complex and seem not to be any faster when reduced to code.
*
* This implementation is based on Arai, Agui, and Nakajima's algorithm for
* scaled DCT. Their original paper (Trans. IEICE E-71(11):1095) is in
* Japanese, but the algorithm is described in the Pennebaker & Mitchell
* JPEG textbook (see REFERENCES section in file README). The following code
* is based directly on figure 4-8 in P&M.
* While an 8-point DCT cannot be done in less than 11 multiplies, it is
* possible to arrange the computation so that many of the multiplies are
* simple scalings of the final outputs. These multiplies can then be
* folded into the multiplications or divisions by the JPEG quantization
* table entries. The AA&N method leaves only 5 multiplies and 29 adds
* to be done in the DCT itself. Вот что надо пробовать улучшать, а не говорить, что "у нас есть такие приборы" (это я про "методы ускорения преобразования Фурье")...
--------------------
"Практика выше (теоретического) познания, ибо она имеет не только достоинство всеобщности, но и непосредственной действительности." - В.И. Ленин
|
|
|
|
|
|
|
|
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0
|
|
|
