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

Подскажите где можно взять примеры реализации 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, то там арифметик упаковывает с точностью до байта.