Приветствую всех.

У micron-а (http://www.micron.com/) быть множество КМОП матриц, и даже систем на кристалле.
Что интересно - у них имеются матрицы с выходом в форматах JPEG 4:2:2, JPEG 4:2:0. Вроде то же самое быть и у, к примеру OmniVision... У микрона это, к примеру, MT9D131 (http://www.micron.com/products/partdetail?part=MT9D131C12STC)
Чо тут хорошего? Думаю, это удобный вариант для использования в IP камерах. Поток можно по изернету передать, т.к. он уже сжат.

Так вот - подскажите, пожалуйста:
- что же это за JPEG 4:2:2, JPEG 4:2:0 (описание там, скорости потока...)?
- нет ли у кого опыта применения матриц микроновских? тогда, может, поделитесь...
- может быть у кого имеется более подробное описание микронов?

Ах да, совсем забыл - их купить то где можно поштучно?

Если интересует что такое JPEG4:2:2 и JPEG 4:2:0
То тут все просто, 4:2:2 и 4:2:0 показывает вам какой формат картинки был сжат джипегом.
Как известно, несжатая цветная картинка как правило представляется в двух форматах RGB или YUV (для джипег правильнее писать YCbCr, но мне так проще). С RGB все просто - это три цветосостовляющие. YUV состоит из чернобелого поля Y и двух цветоразностных составляющих U и V. Если мы картинку например 640х480 перекодируем "as is" из RGB в YUV то получим YUV4:4:4 формат - т.е. все три поля Y, U и V будут по 640х480 байт. Но как выясняется что YUV картинка существенно не теряет в качестве если UV поля уменьшить в два раза по оси Х - это YUV 4:2:2 формат. Другими словами, Y(640х480 байт), U(320х480 байт) и V(320х480 байт). В байтном потоке это выглядит как одна светоразностная компонента на два игрека: YUYVYUYVYUYV... Заметьте, что уже получили сжатие в полтора раза, еще не начав сжимать джипегом .
Ну а с 4:2:0 это сжатие в два раза не только по оси X но и по Y. Другими словами, Y(640х480 байт), U(320х240 байт) и V(320х240 байт). Качество хуже, но начальное ужимание в два раза часто себя оправдывает.

Потом к этим картинкам применяется Джипег. Если хотите прикинуть как ужмется то можно поделить на 30. Я считаю это максимумом - можно добиться и большего сжатия но качество будет уже не очень. Другими словами: YUV4:4:4 640х480 это 900 кБайт несжатого и примерно 30 кБайт сжатого, при переходе на YUV4:2:2 получает 20 кБайт сжатого изображения, при переходе на YUV4:2:0 получает 15 кБайт сжатого изображения

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


1) 565RGB - два байта на пиксель.
555RGB и 444RGB - примерно тоже самое, но 15 и 12 бит на пиксель.
Т.е. это наиболее простое представление, RGB
2) ITU-R BT.601 (YCbCr) - глядя на эту рекомендацию (https://www-inst.eecs.berkeley.edu/~cs150/Documents/ITU601.PDF), начинаю путаться - в каком же виде все-таки представляются здесь выходные данные, я так понял что это вообще PAL...

Я так понимаю, что формат 565RGB можно отнести к 4:2:2, а 555RGB и 444RGB - 4:4:4.
Тогда ITU-R BT.601 (YCbCr) - это тоже 4:2:2, т.е. 6 бит на яркость, по 5 бит на цветоразностные.
Я правильно понимаю или нет?
Поясните, пожалуйста, подробнее, что же тогда 4:2:0.

В связи с вышесказанным первый вопрос:
- что можно почитать, где четко и ясно написано как связать 4:2:2 и прочее с YUV, YCbCr (между которыми разницы не вижу)? Желательно на русском.

И второй вопрос:
- формат JPEG 4:2:2 (0) - это сжатие каждого кадра в JPEG, тогда какой конкретно выходной поток данных (ведь не в виде же файла)... Если я буду гнать этот поток, к примеру через USB, в компьютер, то не должно возникнуть серьезных проблем с выводом, а если надо декодировать в специализированном устройстве...

Как раз в виде файлов! формат файла JFIF (как правило). С ip камеры это достается по фтп протоколу (у нас так). И речь идет о одной статической картинке, затем вы выгребаете другую ит.п. Но если речь идет именно о ВИДЕО-потоке (непрерывной последовательности кадров) и джипег необходим то нужно делать MJPEG (моушн джипег) тогда информация ляжет в хидерах.

RGB и YUV принципиально разные форматы представления картинки, да RGB 555 и RGB565 занимают столько же сколько YUV420 но в последнем случае чернобелая составляющая не коцается а урезается только две цветовые поднесущие. В первом случае урезаются три цветовых компоненты - качество хуже. Если у вас джепег апег ит.п. забудте о RGB. Вспомните о нем когда распакуете поток и видео на экран гнать будете.

Разница между YUV и YCrCb минимальна но существенна. В одном случае это положительный от 0 до 255 сигнал цветовой состовляющей, а в другом случае занкопеременный от -128 до 127. Переход от одного к другому осущестляется простым сдвигом динамического диапазона (прибавить или вычесть 128 математически)

Книга вам нужна "Video Demystified" к сожалению у меня только на английском. Если что пишите выложу гденить в инете

Посмотрел в инете содержание книги - вроде неплохая книга, жаль што с аглицким у меня туговато. Но все равно придется преодолевать эту проблему, поэтому буду благодарен, если ее где-нибудь выложыте.

Тем не менее, может кто знает русскоязычную книгу с подобной тематикой? Автрор, название, ссылки....

torik, удалось решить последний вопрос:со штучной покупкой ? Если получится, поделитесь pls.

выслал ссылку вам на мыло

Простите - по этой ссылке нет доступа (к фтп нет доступа)
может, если не очень весомое - на torizin-liteha@mail.ru?

К сожалению MT9D131 выдаёт данные не в виде файла в параллельный интерфейс.
Выдаётся только пожатое изображение. JFIF заголовки надо самому создавать, таблицы коэффициентов вытаскивать или заливать в кристал по I2C.

Где взять поштучно не знаю, брал кит AES-ANA-BFV-2MP-G (AVNET DESIGN SERVICE) через Макро Групп за 20тр.

Пожалуй проще самому сжать в ПЛИСе либо кодек внешний поставить. У микрона быть и другие хорошие матрицы без сжатия...

А может где пример использывания этой матрицы завалялся?

Простите за тупой вопрос. А откуда эти коэффициенты брать?

Сообщение отредактировал Vitaliy_ARM - Sep 4 2008, 09:27

http://www.w3.org/Graphics/JPEG/itu-t81.pdf

Вникаю, но еще лес пока темный.
Сделал недавно макетку. Хочу сделать, чтобы плата хотя бы зажила. Но для этого надо зашить в камеру эти таблицы. Можно ли их взять с исходников готовых JPEG кодеков?

opencores.org : video compression system например