Тут по алгоритмам сплошь страшные всякие названия... Видать все очень продвинутые. Может кто поможет?
Нужен исходник на С алгоритма "сжатия/разжатия" JPEG. Вопрос вроде известный. Тем не менее ничего простенького не нашел.

А простенького и нет. Классические исходники тут - http://www.ijg.org/

Более-менее кастрированный кодер (для ЧБ) я тут на форуме выкладывал, поищите внимательнее.

Судя по вот этому -- http://el-izdanie.narod.ru/ особо сложного ничего и нет. Только там формулы непонятные несколько...
И описание нечеткое.

Неужели никто и никогда не писал фак по кодированию/декодированию по шагам и подробно!!!
Да не может такого быть... Этот с..... JPEG уже сто лет существует...

ЧБ поищу, спасибо.

А зачем? Это такое сито небольшое, отсеивает халявщиков

Жадные вы все:-))) Сам не ам и другим не дам...

Я, кажется, прямо указал, что "выложено".



Мы-то как раз уже откушали

Все... Что хотел , то и нашел. На этом же форуме. Прекрасные исходники. Я счастлив.
Ваш тоже глянул -- у меня мозг уже старый такое количество директив отсеивать. Но... спасибо.
Тоже откушаю :-)))

Одно фигово -- кодируется все не в потоке.

В смысле?

В прямом -- в тех исходниках сначала в буфер загоняется весь кадр.

По меньшей мере надо буферизировать 8 строк (это для чб, причем без всякого интерлива). Так что идеального потока не будет никогда.

Да ... У меня получается буфер 10240 байт(640х480).

Rst7! Ты ж гуру -- измерял время преобразования?
У меня получается, что надо преобразовать 80 квадратиков 8х8 за 83 мкс при съеме 25 кадров/сек.
Не шибко много времени.
В то же время у омни есть медиапроцессоры для камер -- пишут что на выходе до 9fps. А ведь там стоит 51-й камень.
Мож и АРМ7 хватит или Cortex?

Для цветного изображения это правильная цифра.



Вы. На этом форуме ценят корректность.



Непонятный подсчет. Откуда 83 мкс? За время 40мс (25 кадров в секунду) надо обработать 4800 квадратов ч/б плюс 2*1200 квадратов для цвета.



В 51ом камне там только бизнеслогика. Остальное - аппаратные ускорители.



Считайте сами. При сжатии 1:10 расход на ARM7 примерно 55 тактов на точку (для ч/б, для цветного - примерно 80).

А кто-нить, что-нить писАл для JPEG2000? Меня интересует вменяемое описание(желательно на русском) - ибо исходники для BSD/Linux найти не проблема, но надо же еще и понимать о чем речь...
P.S.: а вообще есть такое понятие как mJPEG2000? Уж больно хорошо жмется(на порядок лучше JPEG) - находка для всяких охранных систем...

На русском - врядли, а так все тут - http://www.jpeg.org/jpeg2000/index.html

Курите на здоровье

//Вы. На этом форуме ценят корректность.

Вы извините меня...


//Непонятный подсчет. Откуда 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).
Судя по приведенным цифрам, хватает даже на цветность... Но ведь где-то грабли лежат наверняка...





А мне и JPEGa хватит...

Для 51го - не хватит.



По каким цифрам? Кому хватает?

Спасибо, но то, только для избранных

Вы только что привели 80 тактов на точку для АРМ7. 640*480*80=24576000 тактов. Или Вы имели ввиду какие-то другие такты?

Привел. Имеем 25 миллионов тактов на кадр. При тактовой 100МГц имеем 4 кадра в секунду.



А тут (сайт тот же ) - http://www.jpeg.org/public/fcd15444-1.pdf

Если принять за истину эти 80 тактов на точку... Тогда АРМ9 надо.
Есть, правда ,небольшие лазейки...
Если запускать программу кодер в памяти АРМ7 скорость несомненно возрастет в разы, верно?
Плюс к этому если данные уже приходят в формате YUV4:2:2 or 4:2:0 , а не преобразовываются из RGB ?
Ну и еще -- если все таки использовать 320 на 240
Что Вы об этом думаете?

спасибо... просматриваю... непонятно, но здорово!

Их нет. Данные по тактам - для выполнения из ОЗУ. И никакого матрицирования нет (т.е. уже YUV на входе).

Жаль... Только если скатиться 320х240(11-12 кадров/сек) или использовать CortexM3 LPC17XX 352x288.
Спасибо дорогому товарищу Rst7...

Вот тут еще немного циферок
http://www.analog.com/en/embedded-processi...rs/product.html
по тактам на точку раза в два примерно получше, но на то оно и DSP.

Число все-же ближе к 1.5. 80 тактов на точку - это умноженное на 1.5 число тактов для ЧБ. Реально - немного лучше. Но на фоне того, что BF имеет под полгигагерца тактовую - это все меркнет (даже то, что BF как ракета вычисляет DCT и здорово тупит над Хаффманом).

Нашел упоминание о быстром алгоритме вычисления DCT -- заранее вычисляется некая матрица и в момент преобразования умножается на NxN матрицу.
Вроде как быстрее намного...

Ссылку в студию. Хотя, я лично очень сомневаюсь.

http://articles.org.ru/docum/jpeg.php

Пейсатели блин...



Набор слов. Не читайте перед обедом советских газет (ЦЭ).



Вот что надо пробовать улучшать, а не говорить, что "у нас есть такие приборы" (это я про "методы ускорения преобразования Фурье")...

Ладненько... :-))) Погладим, что получится -- платку заказал универсальную под LPC3250, 2478 и 1768.

Rst, ты за прошедшую пятилетку повзрослел и можешь вытерпеть прямое обращение, или только "Вы" ?
Ведь к Господу в "Отче наш" мы обращаемся на Ты !.. И дети ко всем

По-прежнему очень актуален вопрос кратких исходников для jpeg2000 и всего прочего сжимательного, 20К для монохромного jpeg мне очень нравятся !
Хоть можно в отладчике походить и обозреть своими старыми мозгами, что же там на самом деле происходит !
А Жасперы и ОпенГугловый проект (очень похожие по своим каталогам) лишь замутняют понимание (кроме всех пожираемых ресурсов) вместе со всеми "направляющими х.з. куда" спецификациями на нехороших языках (которые тоже можно изложить в 5 раз короче и на порядок понятней), это слишком большая цена за вход в "мафиозные сжатые круги".
Надо "русской" стороне сопротивляться всем западным извра-методам, переводить больше всего, "познавшим всю прелесть" писать методички на форумах, типа этого, по кафедрам, "не лягать" под этих отщепенцев и "тягателей одеяла под себя" испокон веков, учить их уму-разуму, свои стандарты придумывать, на 2 порядка более простые, и сразу к ним C-VHDL-реализацию публиковать -- так оно приличней для русскоязычного народа !
Неужели все так и довольствуются Жасперами "для бедных" -- типа бус и погремушек для индейцев от Колумба, и никто не выцепил самую суть для отдачи братьям по разуму ?

jpeg2000 сжимает лучше за счёт арифметического кодера, причём учитываются значения окружающих точек.
И не забываем про полнокадровый Вавелет в двух направлениях.

Blackfin561@500MHz сжимал цветной кадр 640*480 за 13 секунд - широкое поле для оптимизации...

лучшесть jpeg2000 в значительной степени притянута за уши. Можно полюбопытствовать в гугеле и убедиться в этом.
Что касается поля оптимизации, то его практически нет. Причина прозаична - обработке подвергается каждый бит в каждом отсчете преобразования.

Так что имеет смысл 100500 раз подумать, стоит ли выигрыш в снр на 2-3 дб при приемлемом качестве картинки неимоверного роста объема вычислений...

кто мешает тогда в обычном jpege вместо хаффмана арифметический кодер использовать?
после убирания нулей в RLE гистограмма не такая узкая чтобы заметная разница была из-за того, что хаффман позволяет только целое количество бит/символ, а арифметический - дробные.


радости от полнокадрого вэйвлета? просто теперь артефакты сжатия будут не в виде квадратиков 8х8, а в виде замыливания всего кадра.
то что там по циферкам каких-то лишних пара дБ добавятся, на глаз не особо заметно.


что-то очень уж долго, не должно там разницы с обычным jpegом быть в 200 раз быть.

Там же наверное Жасперная библиотека была с замутнением процесса через тучу вложенности и float ?
Клянусь клятвенно, если разберусь по куче исходников, где трудно выцепить, где же там основной объём работы прячется, и оптимизируется всё в один файл, тапа как у Rst, продолжить его приличную традицию "Бог велел делиться", несмотря на то, что у нас на фирме "интеллектуальная собственность всех работников принадлежит руководству".
В связи с санкциями очень хотелось бы аппаратный кристалл кодека видео во всякие крутые форматы -- "jpeg у всех есть", как тут давно написано, просто на всю страну можно, думаю, организовать потребность в десятки тысяч годовых экземпляров, чем в дорогие ПЛИС всё толкать, объединение опять же пойдёт на пользу перед лицом внешних проблем. Технологии штамповки ж у нас есть хотя бы 15-летней давности, когда зарождались ADV2** всякие ? Чем каждому сидеть в уголке и свою косточку грызть -- которых западенцы нам накидали для разъединения ?
Интерфейсы у Рус-hard-кодека могут быть попроще "ад"-ских -- 2-направленная 8-битная шина к ПЛИС типа ULPI и 32-битная к процессору или AMB-е, никакого особо программирования и заливки 32 К кода в SoC -- пнул размеры и тип кодирования и побежал данные совать-доставать...

> кто мешает тогда в обычном jpege вместо хаффмана арифметический кодер использовать?

Наружу хочется компатибельное видео, как записалось в девайсе -- так и выдавать потребителю на просмотр, без дополнительных преобразований и писания своих кодеков. Хотя если у кого есть реализации под обычные проигрыватели -- опять же "Прошу Паны !".

Арифметическое кодирование считается более медленным из-за своей нетабличности, не уверен насчёт "каждый бит в каждом отсчете" после беглого знакомства -- вроде ж надо утоптать 1 коэффициент вэйвлета к предыдущим в отрезок в соответствии с текущей весовой долей и позицией, всё в целых числах, для ПЛИС/ASIC такая задача должна быть детской из-за параллельности, ну а в проце частота больше, деления только не у всех есть быстрые, но можно опять же через умножение-сдвиг выкрутиться.

Лет 20 назад - мешали лицензионные и вычислительные ограничения, сейчас - используют то, под что есть готовые библиотеки.



Ну мы тут тестировали несколько сторонних кодеков, и как-бы не пара Дб да и на глаз разница в очевидна:
Нажмите для просмотра прикрепленного файла



Не должно, но 10 секунд из 13 занимало именно арифметическое сжатие, так что оптимизацию надо с него начинать...

разница на глаз очевидна, только несмотря на то, что надпись сименс в углу и кусок желтого крана в правом нижнем углу и кромки бетонных плит выглядят заметно чётче, у чувака пропала часть уха, куда-то делись зубы, и лицо выглядит весьма помятым (тени на морде) и появились узоры на каске, так же и отдельные дефекты на бетонной плите в виде небольших чёрных точек пораждают вокруг себя весьма заметные артефакты. а нерезкие границы вроде каста/бетон или куртка/бетон сильно размазаны.
то есть при формальных 6дБ разницы по цифиркам, сказать что картинка в стала в два раза лучше ну никак нельзя.
просто артефаты стали другими, и на некоторых картинках будут мало заметны, а на некоторых выглядят даже хуже.

индусские примеры выложенные на сайте ADI дают 50 тактов на пиксель для всего jpega, и 40-190, а в среднем 50-100 тактов на символ для арифметического энкодера, так что раза в 3 разницы еще можно поверить, но не в 200.

_pv, поправьте, если ошибаюсь, но jpeg2000 в отличии от классического (ISO 10918-1:1994) позволяет область лица, заранее определенную прочими алгоритмами, сжать с меньшим коэффициентом сжатия. В современных фотоаппаратах, вроде, кодирование так и происходит.

Добавлю, что практически в любой книге про сжатие фото/видео при описании объективных метрик указывается несовершенство этих методов именно в контексте субъективного человеческого восприятия лиц, человеческих глаз и т.п.

Поэтому надо, конечно, как-то более комплексно сравнивать или с оговорками.