JPEG Compression

[AlmazRa]

Рассматриваю вариант подключения сенсора к микроконтроллеру для последующей передачи изображения по радиоканалу.

1. Наиболее дешевым на мой взгляд сенсором является сенсор от WEB-камеры. Сенсор "не мечта миллионов" и качество картинки оставляет желать лучшего, но его стоимость очень приемлема для экспериментов.

2. Исследовав несколько очень дешевых WEB-камер обнаружил наличие сенсора VA6241.
Достаточно легкая в отношении пайки, подключения питания и т.п. Нашёл на него самопальный датащит... http://www.vabolis.lt/stuff/VA6241.pdf

Вопросы.
1. Управление по I2C шине... Нет регистров.
- как вариант решения предполагаю "слушать" микроконтроллером в процессе работы камеры с компом.
? может у кого есть готовые регистры?
? регистры стандарт или у каждого чипа свой?

2. Как сжать полученную картинку? Даже на 8bit'ах из 10-ти возможных получается очень большой поток.
640 dot*480 line* 30fps * 8 bit = 74Mbit
предполагаю 320*240*15*8=9Mbit
- реализовать на микроконтроллере сложно, скорее даже не реально. Слишком большой поток - AVR Atmega не протянет...
? Или я ошибаюсь. Может кто делал?
- специальна микросхема JPEG-кодек. Большое изобилее судя по интернету.
? Существует ли какие-то более распространённые, употредбительные. Кто с какими работал?

3.? Может у кого есть ещё какие идеи?

p.s.
Проанализровав интернет
1. как вариант есть использоватик фотик от телефона, но это НЕ рассматривается. Потому как много камер от телефонов не найти.
2. Встроенный кодек в камере (VC0305) - к сожалению даёт выход только на USB(((
3. В цифровых фотиках как я понял всё зашито в осноной чип, т.е. кодек - это не отдельная микруха(((

[NiTr0]

Где-то я встречал на просторах инета проект сжатия в JPEG с помощью AVR, с какой-то аналоговой камеры + внешнего АЦП... Если ессно память не подводит.
Вот навскидку.

[AlmazRa]

Спасибо. Полезная ссылка. На ARM никто не пробывал делать? Производительность действительно поболе будет!

[ELcat]

Братцы, такая хорошая тема пылится - воскресим?..

Сам недавно заинтересовался JPEG форматом, а именно декодированием силами AVR-ки с последующим отображением... да пускай тем же ls020 от всем известного Siemens S65. Прочесав просторы Интернета, наткнулся на это: http://habrahabr.ru/blogs/algorithm/102521/ . Курил несколько раз и даже почти во всём въехал. Автор, конечно, молодца! Всё разжёвано и разложено "по полочкам". Только вот, как он сам описывает, на "большом брате" по его алгоритму картинка 600х600 распаковывалась ок. 7 секунд. После оптимизации алгоритма, которой он самым "вежливым" способом не поделился, ок. 15мс. Тогда сколько же по времени будет длиться этот процесс на маленькой AVR-ке? Исходя из описанного алгоритма и по предварительным прикидкам, можно надеяться вместиться в 1 кил RAM, если обрабатывать по одному блоку 8х8 и сразу же плученный результат 3х8х8 (RGB) выбрасывать в дисп, освобождая место под новый вычисляемый блок. Только возникает ещё один вопрос, как оптимизировать вычисление AC составляющей, ведь именно в этом процессе лежит львиная доля всех вычислений.

[Satyr]

http://elm-chan.org/fsw/tjpg/00index.html

но про AVR, ессно, забудьте.
Кстати, среди кортексов хватает МК сразу с CIS интерфейсом за недорого.

Например, STM32F207 . небольшой корпус - 64 ноги, 150 MIPS (поржем вместе над AVRом -)) ), в России в наличии от 200р

Digital camera interface (DCMI)
The camera interface is not available in STM32F205xx devices.
STM32F207xx products embed a camera interface that can connect with camera modules
and CMOS sensors through an 8-bit to 14-bit parallel interface, to receive video data. The
camera interface can sustain up to 27 Mbyte/s at 27 MHz or 48 Mbyte/s at 48 MHz. It
features:
● Programmable polarity for the input pixel clock and synchronization signals
● Parallel data communication can be 8-, 10-, 12- or 14-bit
● Supports 8-bit progressive video monochrome or raw Bayer format, YCbCr 4:2:2
progressive video, RGB 565 progressive video or compressed data (like JPEG)
● Supports continuous mode or snapshot (a single frame) mode
● Capability to automatically crop the image

[ELcat]

Я в ARM-овских камушках и сам худо-бедно ориентируюсь, но интересует реализация именно на 8-бит AVR-ке На кортексе не прикольно - при помощи гранаты любой рыбы наловить сможет, но это же тоже не прикольно

[Avarges]

интересует реализация именно на 8-бит AVR-ке

Все-таки у атмеги 16 MIPS, с камерами и LCD по серьезному не развернешься.

Код этот http://elm-chan.org/fsw/tjpg/00index.html интересный, но на си. Вот если на ассемблере его переписать, будет раз в 5 быстрее всё делать. Только где найти такого мазохиста?

Вообще изначально надо понять какая задача. полкадра в секунду устраивает или нет?

[ELcat]

Нет, вы не подумайте, я не извращенец, но заставил мегу 16 работать на 25МГц от 3,6-4В (ли-ион АКБ от мобилки). Я не говорил, что хочу камеру прикрутить - просто чтение из памяти и распаковка с выводом на экран. Кстати ни у кого нету готовой "полноценной" библиотечки для работы с FAT32? Желательно под КодВижнАВР? А то всё что я находил было или урезанным функционально или не рабочим...

[Avarges]

А я и сам этим вопросом заинтересован, как на атмеге8, с прикрученным чипом USB CP2102 достичь нормальной отрисовки. На деле получается канал 90Кбайт/с, если кидать несжатые данные в дисплей, то у меня получилось 1.8 FPS, упирается в канал прежде всего (дисплей 128*128*12бит), потому что сам дисплей заводится на атмеге на 15 кадров в секунду. JPEG позволяет зажать примерно в 10 раз, но тяжелый для 8 битных контроллеров и написан не для них. Тут нужен какой-то упрощенный JPEG без хаффманов и прочих прожорливых вычислений, жмущий в 3-4 раза.
Сам жду почтой Cortex-M3 чип пока балуюсь с атмегой

[ELcat]

TJpgDec is a generic JPEG image decompressor module that highly optimized for small embedded systems. It works with very low memory consumption so that it can be incorporated into tiny microcontrollers, such as AVR, 8051, PIC, Z80, Cortex-M0 and etc.

Ну вот, а говорите АВР-ка не потянет.

[Avarges]

Потянет примерно так

[Satyr]

На кортексе не прикольно - при помощи гранаты любой рыбы наловить сможет, но это же тоже не прикольно

Ну, как то не заметил в начале, что цель затрахаться за дорого, а не решить задачу за дешево.

[Satyr]

TJpgDec is a generic JPEG image decompressor module that highly optimized for small embedded systems. It works with very low memory consumption so that it can be incorporated into tiny microcontrollers, such as AVR, 8051, PIC, Z80, Cortex-M0 and etc.
Ну вот, а говорите АВР-ка не потянет.

"скомпилируется" и "потянет" - это две большие разницы.

[Satyr]

Тут нужен какой-то упрощенный JPEG без хаффманов и прочих прожорливых вычислений, жмущий в 3-4 раза.

Насколько помню, само сжатие по хаффману совсем не страшно на фоне конверсии цветового пространства и DCT, без которого никакого jpeg не будет.

[Satyr]

А я и сам этим вопросом заинтересован, как на атмеге8, с прикрученным чипом USB CP2102 достичь нормальной отрисовки. На деле получается канал 90Кбайт/с, если кидать несжатые данные в дисплей, то у меня получилось 1.8 FPS, упирается в канал прежде всего (дисплей 128*128*12бит), потому что сам дисплей заводится на атмеге на 15 кадров в секунду.

cp2102 с атмегой как связан ?

Пользовал at90usb82 на 16Mhz с дисплеем 320x240x16bit - по USB он выводится ~1с.

[Avarges]

cp2102 с атмегой как связан ?

По UART

Насколько помню, само сжатие по хаффману совсем не страшно на фоне конверсии цветового пространства и DCT, без которого никакого jpeg не будет.

Я о том же, нужно сжатие с потерями оптимизированное под всё это. JPEG не для атмег.

[Satyr]

Я о том же, нужно сжатие с потерями оптимизированное под всё это. JPEG не для атмег.

Я бы сказал иначе - эта задача не для атмег

[ELcat]

Но сия тема именно о JPEG. Больше всего тянет обратное дискретно-косинусное преобразование, но автор приведённой статьи как-то решил эту проблему. Потом никто же не заставляет точно вычислять косинусы, тем более на 8бит машинке. Вполне достаточно будет "зашить" во флешку табличку на 256 значений.

[ELcat]

TJpgDec is a generic JPEG image decompressor module that highly optimized for small embedded systems. It works with very low memory consumption so that it can be incorporated into tiny microcontrollers, such as AVR, 8051, PIC, Z80, Cortex-M0 and etc.
Ну вот, а говорите АВР-ка не потянет.

"скомпилируется" и "потянет" - это две большие разницы.

Не пойму в чём проблема? В одно место никто не толкает, пусть пыхтит се потихоньку. Я же не говорю декодирование в реалтайме и всё такое, так в чём вопрос?

[Мастер Ломастер]

Я о том же, нужно сжатие с потерями оптимизированное под всё это. JPEG не для атмег.

Я бы сказал иначе - эта задача не для атмег

достали вы со спорами AVR vs ARM. можно ломиться в стену на танке ARM, можно влезть в окно на AVR, но правильнее поставить задачу так, чтобы ее можно было решить не через жопу.

есть камера, которая отличненько по UART-у выдает изображения со скоростью 115 кбод, стоит около 350 рублей. такой поток отлично потянет не только AVR, но даже классический MCS51. если вы собрались передавать этот поток по радиоканалу, то можно построить схему так, что из камеры байты сразу попрут в передатчик - МК нужно будет только инициировать работу.

камера ищется по ключевым словам CoMedia Camera такая вот комедия, блин.

если на ARM или еще какой-то фигне можно получить более простое и дешевое решение - напишите.

Разумеется, речь не о передаче видео, а о статических изображениях. но это изначально подразумевалось, т.к. JPEG - это метод сжатия неподвижных изображений, в отличие от MPEG. в реале с этой камеры получается до 5 кадров в секунду (при малом разрешении и черно-белым - больше)...