Здравствуйте!

Подскажите где можно взять примеры реализации JPEG(МJPEG) для процессора TMS320DM643... , также примеры на С для других процессоров. Так же нужна информация по оптимизации алгоритма JPEG.

За любую информацию буду благодaрен.

Сергей.

Поищите по форуму, я выкладывал исходник JPEG-кодера, довольно серьезно оптимизированного. Изначально под ARM, но порт на другую архитектуру не составляет труда. Правда, он с GPL лицензией

Cпасибо за ответ. Сейчас поищу. Есть ещё вопрос. Что на входе и можно ли разархивировать выходной файл стандартными средствами?
Благодарю.

На входе - массив x на y, содержащий яркость в виде "байт на точку". На выходе поток, соответствующий стандартному JPEG.

Токма чёрно-белый и режим сжатия - 1, 2,...
Для потока проще ужимать до ххх бит, ну и лучше цветное 422 или 411

Ну цвет туда вкрутить не долго. А выбросить передачу заголовков - так вообще пыль для моряка

Вместе со стеклянными бусами, зеркальцами и огненной водой белые люди несут племенам дикарей и некоторые свои странные идеи - поклонение распятому религиозному бунтарю, написание программ с открытыми исходными текстами... Это я о том, что открываем любой проект GNU или BSD связанный с JPEG и имеем исходный текст. Кстати, когда-то сюда уже приводили некоторые интересные ссылки...

вот

А вот вообще шедевр... и там далеко не только mJPEG интересен... BlackFin GCC ...

Слабо применимый к реалиям встраиваемого мира - одна необходимость в менеджере кучи чего стоит.

Недавно отсеялся еще на пером этапе собеседования в одну контору. Так вот в Киеве embedded называют Linux в чем-то таком небольшом... где-то так . Так что не во всяком встроенном есть проблемы с кучей. Кстати, а эти TMS320DM643... они что - без OS?

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



Ну вот AVR - с осью или без?

Хороший менеджер кучи, не тормозящий сильно процессы в RTOS и при этом не требующий большого перерасхода озу на заранее заготовленные пулы и являющийся достаточно универсальным (идеал - malloc без указания кучи) - мало того, что нетривиален, так еще и нерешаемый в общем виде. Все равно содержит набор костылей

Социопата с моим опытом врядли что-то расстроит Нет, это не дятлы и как раз с Linux'ом у меня все очень даже хорошо, как и GCC, bash и пррименением libbfdsp . Но нужны еще и C++, алгоритмы 3-D графики или видеообработки, и приэтом какой-то из ARM9... или работа над численными методами ... Не шчу. Контору мы все - знаем .


Ну x86 тоже можно без оси, и прогу из флеши вместо биоса загружать . Дело в том, что мы то не знаем что нужно аФФтару, и что там у него за средствА, но насколько помню к таким процам есть фирменная оська да и сам компилятор обязательно что-то выдумает. Если нужно "на вчера" - GNU jpeg уже выход ...

...не спорю.

Я не про передачу заголовков. А о подборе коэффициентов под картинку так, чтоб независимо от сцены JFIF был всегда одной длины.
Если на AVR это нагрузка на процессор, то на TI или Blackfin - нет.

Ну для этого достаточно 2 раза зажать. Первый раз - для ориентировки, второй - боевой. Хотя, если бы мне надо было обеспечить в среднем одинаковый поток, я бы делал не так - я бы от размера предыдущих кадров крутил бы уровень компрессии.



Я тут AVR не упоминал вообще. Не надо пугать народ

С опозданием, но всем спасибо за предоставленную информацию!

Сергей.

Тогда надо делать более мелкий шаг уровня компрессии. Когда сидишь между 1 и 2 уровнем, то получатся кадры, то по Х байт, то по 2Х байт приблизительно. Соответственно визуально очень сильная разница в качестве между соседними кадрами.

Если посмотреть на реализацию JPEG2000 c Wavelet, то там арифметик упаковывает с точностью до байта.

Если Вы про мой кодер, то достаточно заменить целочисленное деление

на, например, деление на fixed_point 8.8 вот таким способом


В результате будет не 1,2,3, а 0x100...0x200...0x300 с промежуточными значениями.

Не просветите?
Сделал преобразование в RGB таким образом.
Y=Y+128;
Остальные компоненты без изменений.
Далее умножаю, складываю и отнимаю стандартно.
После чего проверяю на диапазон (0-255) и вывожу на экран.
Все воспроизводитсязамечательно. Цвета на моем экране совпадают с оригиналом.

Но.
При воспроизведении картинок с субсамплингом отличным от 1:1 в некоторых местах проявляются странные артефакты.
Практически незаметные на изображениях типа фотографий, и ярко выделяющиеся на простейших изображениях, например, синий квадрат на черном фоне.

При горизонтальной субпикселизации наблюдаю у левой границы квадарата черную полоску (в 7-8 пикселах от левой границы), а справой стороны - синиюю полоску - в 7-8 пикселах ОТ границы квадрата (там где ничего не должно быть.

На оригинале на месте этих моих артефактов есть реальные артефакты. Но слабо выраженные. Изчезающе синяя полоска с правой стороны (уровни яркости компонент не превышают 5) превращается в нормалюную синюю полосу толщиной в пиксель.

Предполагаю, что неправильно преобразую YCR в RGB.

Нажмите для просмотра прикрепленного файла
Типа, снято фотиком с экрана. Все, что имеет странный цвет - чисто синее. Либо белое.
Полоса справа лежит вне реального синего квадрата. Чисто синего.
На месте этой полосы в реальном изображении пипеткой корела обнаруживается некая полоска низкой яркости R=2, G=0, B=9 - такого порядка .

Занимался JPEG кодером и энкодером на асме проца 64х3х.
25 кадров в секунду для одновременного кодирования и декодирования на 640х480 получалось стабильно.
Исходником поделиться не смогу слишком много времени и сил было в это вложено, советом всегда пожалуйста.