| |
 Алгоритм JPEG, JPEG |
|
|
|
|
 Jul 16 2009, 09:57
|
Частый гость
Группа: Участник
Сообщений: 132
Регистрация: 11-07-08
Пользователь №: 38 870
|
Цитата(Rst7 @ Jul 16 2009, 10:48)  А простенького и нет. Классические исходники тут - http://www.ijg.org/Более-менее кастрированный кодер (для ЧБ) я тут на форуме выкладывал, поищите внимательнее. Судя по вот этому -- http://el-izdanie.narod.ru/ особо сложного ничего и нет. Только там формулы непонятные несколько... И описание нечеткое. Неужели никто и никогда не писал фак по кодированию/декодированию по шагам и подробно!!! Да не может такого быть... Этот с..... JPEG уже сто лет существует... ЧБ поищу, спасибо.
|
|
|
|
|
|
|
|
Jul 16 2009, 10:37
|
Частый гость
Группа: Участник
Сообщений: 132
Регистрация: 11-07-08
Пользователь №: 38 870
|
Цитата(Rst7 @ Jul 16 2009, 14:24) А зачем? Это такое сито небольшое, отсеивает халявщиков  Жадные вы все:-))) Сам не ам и другим не дам...
|
|
|
|
|
|
|
|
Jul 16 2009, 10:49
|
Йа моск ;)
Группа: Модераторы
Сообщений: 4 345
Регистрация: 7-07-05
Из: Kharkiv-city
Пользователь №: 6 610
|
Цитата Жадные вы все:-))) Я, кажется, прямо указал, что "выложено". Цитата Сам не ам и другим не дам... Мы-то как раз уже откушали
--------------------
"Практика выше (теоретического) познания, ибо она имеет не только достоинство всеобщности, но и непосредственной действительности." - В.И. Ленин
|
|
|
|
|
|
|
|
Jul 16 2009, 10:57
|
Частый гость
Группа: Участник
Сообщений: 132
Регистрация: 11-07-08
Пользователь №: 38 870
|
Цитата(Rst7 @ Jul 16 2009, 14:49) Я, кажется, прямо указал, что "выложено". Мы-то как раз уже откушали Все... Что хотел , то и нашел. На этом же форуме. Прекрасные исходники. Я счастлив. Ваш тоже глянул -- у меня мозг уже старый такое количество директив отсеивать. Но... спасибо. Тоже откушаю :-)))
|
|
|
|
|
|
|
|
Jul 17 2009, 07:15
|
Частый гость
Группа: Участник
Сообщений: 132
Регистрация: 11-07-08
Пользователь №: 38 870
|
Цитата(Step_ARM @ Jul 16 2009, 14:57) Все... Что хотел , то и нашел. На этом же форуме. Прекрасные исходники. Я счастлив.
Ваш тоже глянул -- у меня мозг уже старый такое количество директив отсеивать. Но... спасибо.
Тоже откушаю :-))) Одно фигово -- кодируется все не в потоке.
|
|
|
|
|
|
|
|
Jul 17 2009, 08:26
|
Частый гость
Группа: Участник
Сообщений: 132
Регистрация: 11-07-08
Пользователь №: 38 870
|
Цитата(Rst7 @ Jul 17 2009, 11:40) В смысле? В прямом -- в тех исходниках сначала в буфер загоняется весь кадр.
|
|
|
|
|
|
|
|
Jul 17 2009, 10:26
|
Частый гость
Группа: Участник
Сообщений: 132
Регистрация: 11-07-08
Пользователь №: 38 870
|
Цитата(Rst7 @ Jul 17 2009, 12:28) По меньшей мере надо буферизировать 8 строк (это для чб, причем без всякого интерлива). Так что идеального потока не будет никогда. Да ... У меня получается буфер 10240 байт(640х480). Rst7! Ты ж гуру -- измерял время преобразования? У меня получается, что надо преобразовать 80 квадратиков 8х8 за 83 мкс при съеме 25 кадров/сек. Не шибко много времени. В то же время у омни есть медиапроцессоры для камер -- пишут что на выходе до 9fps. А ведь там стоит 51-й камень. Мож и АРМ7 хватит или Cortex?
|
|
|
|
|
|
|
|
Jul 17 2009, 10:41
|
Йа моск ;)
Группа: Модераторы
Сообщений: 4 345
Регистрация: 7-07-05
Из: Kharkiv-city
Пользователь №: 6 610
|
Цитата Да ... У меня получается буфер 10240 байт(640х480). Для цветного изображения это правильная цифра. Цитата Ты Вы. На этом форуме ценят корректность. Цитата У меня получается, что надо преобразовать 80 квадратиков 8х8 за 83 мкс при съеме 25 кадров/сек. Непонятный подсчет. Откуда 83 мкс? За время 40мс (25 кадров в секунду) надо обработать 4800 квадратов ч/б плюс 2*1200 квадратов для цвета. Цитата В то же время у омни есть медиапроцессоры для камер -- пишут что на выходе до 9fps. А ведь там стоит 51-й камень. В 51ом камне там только бизнеслогика. Остальное - аппаратные ускорители. Цитата Мож и АРМ7 хватит или Cortex? Считайте сами. При сжатии 1:10 расход на ARM7 примерно 55 тактов на точку (для ч/б, для цветного - примерно 80).
--------------------
"Практика выше (теоретического) познания, ибо она имеет не только достоинство всеобщности, но и непосредственной действительности." - В.И. Ленин
|
|
|
|
|
|
|
|
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. Вот что надо пробовать улучшать, а не говорить, что "у нас есть такие приборы" (это я про "методы ускорения преобразования Фурье")...
--------------------
"Практика выше (теоретического) познания, ибо она имеет не только достоинство всеобщности, но и непосредственной действительности." - В.И. Ленин
|
|
|
|
|
|
|
|
Jul 20 2009, 10:29
|
Частый гость
Группа: Участник
Сообщений: 132
Регистрация: 11-07-08
Пользователь №: 38 870
|
Цитата(Rst7 @ Jul 20 2009, 11:42) Пейсатели блин...
Набор слов. Не читайте перед обедом советских газет (ЦЭ).
Вот что надо пробовать улучшать, а не говорить, что "у нас есть такие приборы" (это я про "методы ускорения преобразования Фурье")... Ладненько... :-))) Погладим, что получится -- платку заказал универсальную под LPC3250, 2478 и 1768.
|
|
|
|
|
|
|
|
Sep 12 2014, 09:59
|
Местный
Группа: Свой
Сообщений: 271
Регистрация: 6-12-11
Из: Taganrog
Пользователь №: 68 701
|
Цитата(Rst7 @ Jul 17 2009, 14:41) Вы. На этом форуме ценят корректность. Rst, ты за прошедшую пятилетку повзрослел и можешь вытерпеть прямое обращение, или только "Вы" ? Ведь к Господу в "Отче наш" мы обращаемся на Ты !.. И дети ко всем  По-прежнему очень актуален вопрос кратких исходников для jpeg2000 и всего прочего сжимательного, 20К для монохромного jpeg мне очень нравятся ! Хоть можно в отладчике походить и обозреть своими старыми мозгами, что же там на самом деле происходит ! А Жасперы и ОпенГугловый проект (очень похожие по своим каталогам) лишь замутняют понимание (кроме всех пожираемых ресурсов) вместе со всеми "направляющими х.з. куда" спецификациями на нехороших языках (которые тоже можно изложить в 5 раз короче и на порядок понятней), это слишком большая цена за вход в "мафиозные сжатые круги". Надо "русской" стороне сопротивляться всем западным извра-методам, переводить больше всего, "познавшим всю прелесть" писать методички на форумах, типа этого, по кафедрам, "не лягать" под этих отщепенцев и "тягателей одеяла под себя" испокон веков, учить их уму-разуму, свои стандарты придумывать, на 2 порядка более простые, и сразу к ним C-VHDL-реализацию публиковать -- так оно приличней для русскоязычного народа ! Неужели все так и довольствуются Жасперами "для бедных" -- типа бус и погремушек для индейцев от Колумба, и никто не выцепил самую суть для отдачи братьям по разуму ?
|
|
|
|
|
|
|
|
Sep 12 2014, 12:55
|
Знающий
Группа: Участник
Сообщений: 781
Регистрация: 3-08-09
Пользователь №: 51 730
|
Цитата(_4afc_ @ Sep 12 2014, 15:12) jpeg2000 сжимает лучше за счёт арифметического кодера, причём учитываются значения окружающих точек.
И не забываем про полнокадровый Вавелет в двух направлениях.
Blackfin561@500MHz сжимал цветной кадр 640*480 за 13 секунд - широкое поле для оптимизации... лучшесть jpeg2000 в значительной степени притянута за уши. Можно полюбопытствовать в гугеле и убедиться в этом. Что касается поля оптимизации, то его практически нет. Причина прозаична - обработке подвергается каждый бит в каждом отсчете преобразования. Так что имеет смысл 100500 раз подумать, стоит ли выигрыш в снр на 2-3 дб при приемлемом качестве картинки неимоверного роста объема вычислений...
|
|
|
|
|
|
|
|
Sep 12 2014, 13:48
|
Гуру
Группа: Свой
Сообщений: 2 563
Регистрация: 8-04-05
Из: Nsk
Пользователь №: 3 954
|
Цитата(_4afc_ @ Sep 12 2014, 18:12) jpeg2000 сжимает лучше за счёт арифметического кодера, причём учитываются значения окружающих точек. кто мешает тогда в обычном jpege вместо хаффмана арифметический кодер использовать? после убирания нулей в RLE гистограмма не такая узкая чтобы заметная разница была из-за того, что хаффман позволяет только целое количество бит/символ, а арифметический - дробные. Цитата(_4afc_ @ Sep 12 2014, 18:12) И не забываем про полнокадровый Вавелет в двух направлениях. радости от полнокадрого вэйвлета? просто теперь артефакты сжатия будут не в виде квадратиков 8х8, а в виде замыливания всего кадра. то что там по циферкам каких-то лишних пара дБ добавятся, на глаз не особо заметно. Цитата(_4afc_ @ Sep 12 2014, 18:12) Blackfin561@500MHz сжимал цветной кадр 640*480 за 13 секунд - широкое поле для оптимизации... что-то очень уж долго, не должно там разницы с обычным jpegом быть в 200 раз быть.
|
|
|
|
|
|
|
|
Sep 15 2014, 06:56
|
Местный
Группа: Свой
Сообщений: 271
Регистрация: 6-12-11
Из: Taganrog
Пользователь №: 68 701
|
Там же наверное Жасперная библиотека была с замутнением процесса через тучу вложенности и float ? Клянусь клятвенно, если разберусь по куче исходников, где трудно выцепить, где же там основной объём работы прячется, и оптимизируется всё в один файл, тапа как у Rst, продолжить его приличную традицию "Бог велел делиться", несмотря на то, что у нас на фирме "интеллектуальная собственность всех работников принадлежит руководству". В связи с санкциями очень хотелось бы аппаратный кристалл кодека видео во всякие крутые форматы -- "jpeg у всех есть", как тут давно написано, просто на всю страну можно, думаю, организовать потребность в десятки тысяч годовых экземпляров, чем в дорогие ПЛИС всё толкать, объединение опять же пойдёт на пользу перед лицом внешних проблем. Технологии штамповки ж у нас есть хотя бы 15-летней давности, когда зарождались ADV2** всякие ? Чем каждому сидеть в уголке и свою косточку грызть -- которых западенцы нам накидали для разъединения ? Интерфейсы у Рус-hard-кодека могут быть попроще "ад"-ских -- 2-направленная 8-битная шина к ПЛИС типа ULPI и 32-битная к процессору или AMB-е, никакого особо программирования и заливки 32 К кода в SoC -- пнул размеры и тип кодирования и побежал данные совать-доставать... > кто мешает тогда в обычном jpege вместо хаффмана арифметический кодер использовать? Наружу хочется компатибельное видео, как записалось в девайсе -- так и выдавать потребителю на просмотр, без дополнительных преобразований и писания своих кодеков. Хотя если у кого есть реализации под обычные проигрыватели -- опять же "Прошу Паны !". Арифметическое кодирование считается более медленным из-за своей нетабличности, не уверен насчёт "каждый бит в каждом отсчете" после беглого знакомства -- вроде ж надо утоптать 1 коэффициент вэйвлета к предыдущим в отрезок в соответствии с текущей весовой долей и позицией, всё в целых числах, для ПЛИС/ASIC такая задача должна быть детской из-за параллельности, ну а в проце частота больше, деления только не у всех есть быстрые, но можно опять же через умножение-сдвиг выкрутиться.
|
|
|
|
|
|
|
|
Sep 15 2014, 09:19
|
Профессионал
Группа: Свой
Сообщений: 1 262
Регистрация: 13-10-05
Из: Санкт-Петербург
Пользователь №: 9 565
|
Цитата(_pv @ Sep 12 2014, 17:48) кто мешает тогда в обычном jpege вместо хаффмана арифметический кодер использовать?
после убирания нулей в RLE гистограмма не такая узкая чтобы заметная разница была из-за того, что хаффман позволяет только целое количество бит/символ, а арифметический - дробные. Лет 20 назад - мешали лицензионные и вычислительные ограничения, сейчас - используют то, под что есть готовые библиотеки. Цитата(_pv @ Sep 12 2014, 17:48) радости от полнокадрого вэйвлета? просто теперь артефакты сжатия будут не в виде квадратиков 8х8, а в виде замыливания всего кадра. то что там по циферкам каких-то лишних пара дБ добавятся, на глаз не особо заметно. Ну мы тут тестировали несколько сторонних кодеков, и как-бы не пара Дб да и на глаз разница в очевидна:
Цитата(_pv @ Sep 12 2014, 17:48) что-то очень уж долго, не должно там разницы с обычным jpegом быть в 200 раз быть. Не должно, но 10 секунд из 13 занимало именно арифметическое сжатие, так что оптимизацию надо с него начинать...
|
|
|
|
|
|
|
|
Sep 15 2014, 10:17
|
Гуру
Группа: Свой
Сообщений: 2 563
Регистрация: 8-04-05
Из: Nsk
Пользователь №: 3 954
|
Цитата(_4afc_ @ Sep 15 2014, 16:19) Ну мы тут тестировали несколько сторонних кодеков, и как-бы не пара Дб да и на глаз разница в очевидна: разница на глаз очевидна, только несмотря на то, что надпись сименс в углу и кусок желтого крана в правом нижнем углу и кромки бетонных плит выглядят заметно чётче, у чувака пропала часть уха, куда-то делись зубы, и лицо выглядит весьма помятым (тени на морде) и появились узоры на каске, так же и отдельные дефекты на бетонной плите в виде небольших чёрных точек пораждают вокруг себя весьма заметные артефакты. а нерезкие границы вроде каста/бетон или куртка/бетон сильно размазаны. то есть при формальных 6дБ разницы по цифиркам, сказать что картинка в стала в два раза лучше ну никак нельзя. просто артефаты стали другими, и на некоторых картинках будут мало заметны, а на некоторых выглядят даже хуже. Цитата(_4afc_ @ Sep 15 2014, 16:19) Не должно, но 10 секунд из 13 занимало именно арифметическое сжатие, так что оптимизацию надо с него начинать... индусские примеры выложенные на сайте ADI дают 50 тактов на пиксель для всего jpega, и 40-190, а в среднем 50-100 тактов на символ для арифметического энкодера, так что раза в 3 разницы еще можно поверить, но не в 200.
|
|
|
|
|
|
|
|
Sep 19 2014, 06:21
|
Профессионал
Группа: Участник
Сообщений: 1 273
Регистрация: 3-03-06
Пользователь №: 14 942
|
_pv, поправьте, если ошибаюсь, но jpeg2000 в отличии от классического (ISO 10918-1:1994) позволяет область лица, заранее определенную прочими алгоритмами, сжать с меньшим коэффициентом сжатия. В современных фотоаппаратах, вроде, кодирование так и происходит.
Добавлю, что практически в любой книге про сжатие фото/видео при описании объективных метрик указывается несовершенство этих методов именно в контексте субъективного человеческого восприятия лиц, человеческих глаз и т.п.
Поэтому надо, конечно, как-то более комплексно сравнивать или с оговорками.
Сообщение отредактировал x736C - Sep 19 2014, 06:24
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
