[Manhoso 0]

Где раздобыть программные библиотеки для реализации алгоритма JPEG?

 

Изображение 720х480, 10 бит на пиксель, процессор BF561.

[blackfin 22]

JPEG Encoder

JPEG Decoder

[Manhoso 0]

Эспасибо. А скачать как?

[blackfin 22]

Там ссылка внизу страницы, кроме того:

You must register or log in to download Software Development Kits (SDKs) and Software Modules:

[Manhoso 0]

Тьфуты, точно. Спасибо большое.

[Manhoso 0]

В общем, скачал себе библиотеку, закинул куда нужно, в опциях линкера прописал название и путь к ней - а при компиляции проекта, который использует функции библиотеки libadi_jpeg_encoder_bf.dlb выскочили следующие замечания и ошибки:

 

[Warning li2060] The following input section(s) that contain program code

and/or data have not been placed into the executable for processor 'p0'

as there are no relevant commands specified in the LDF:

 

libadi_jpeg_encoder_bf.dlb[JPEG_api_common.doj](JPEGENC_D0)

libadi_jpeg_encoder_bf.dlb[JPEG_api_common.doj](JPEG_P0)

libadi_jpeg_encoder_bf.dlb[JPEG_api.doj](JPEGENC_P0)

libadi_jpeg_encoder_bf.dlb[JPEG_encoder.doj](JPEGENC_P0)

libmc561y.dlb[mc_data.doj](program)

libio561mty.dlb[primio_atomic_lock_datamt.doj](program)

 

 

[Error li1060] The following symbols are referenced, but not mapped:

'_JPEG_Param_CONFIG' referenced from .\Debug\jpeg.doj(program)

'_JPEG_Encoder_DELETE' referenced from .\Debug\jpeg.doj(program)

'_JPEG_Encoder_NEW' referenced from .\Debug\jpeg.doj(program)

'_JPEG_EncodeImage' referenced from .\Debug\jpeg.doj(program)

 

Linker finished with 1 error and 1 warning

cc3089: fatal error: Link failed

Tool failed with exit/exception code: 1.

Build was unsuccessful.

 

 

Что я сделал не так?

Изменено 2 июня, 2009 пользователем Мухаммор

[Manhoso 0]

Ну тогда какое минимально возможное время преобразования ч/б изображения 720х480 на BF561 при 600 МГц?

[blackfin 22]

Минимально возможное время - один такт DSP = 1/600 uS.

За это время время любое изображение можно сжать в файл размером в один байт.

А если серьезно, то время сжатия зависит от полной вариации исходного изображения, выбранных таблиц Гаффмана и значений коэффициентов квантователя..

Изменено 2 июня, 2009 пользователем blackfin

[Manhoso 0]

Мне, чтоб получить выигрыш, необходимо, чтоб проц ужимал картинку за 30 мс. Это реально?

 

Все-таки, чего компилятор ругается?

[blackfin 22]

Мне, чтоб получить выигрыш, необходимо, чтоб проц ужимал картинку за 30 мс. Это реально?

По первой ссылке:

 

Mandrill......... 512*512: Cycles per Pixel = 120.03

Sf_720x480... 720*480: Cycles per Pixel = 60.93

 

У Вас:

 

720х480: 345600 Pixels * 120.03 = 41482368 Cycles = 69,13728 мс => для ч/б = 46,09152 мс.

720х480: 345600 Pixels * 60.93 = 35,09568 мс. => для ч/б = 23,39712 мс.

 

Всё это на одном ядре BF561.

 

Все-таки, чего компилятор ругается?

Не знаю, я эти либы не пользовал..

[Rst7 5]

Mandrill......... 512*512: Cycles per Pixel = 120.03

Sf_720x480... 720*480: Cycles per Pixel = 60.93

 

Какие-то странные цифры. Помните, когда мой кодер бенчмаркали, на ARM7 получили порядка 4.3 миллиона тактов для ч/б 320*240. Это порядка 56 тактов на пиксель. Явно не двухкратный проигрыш, как мы тогда выяснили. Или это я такой кодер "мочный" состряпал? ;)

 

Кстати, а почему Вы соотношение цветное/чб определили как ~1.5? Я бы ориентировался на 2. Хотя... Там же коэффициенты для деления побольше, значит, нулей тоже побольше... Ну да, где-то полтора будет.

[blackfin 22]

Какие-то странные цифры. Помните, когда мой кодер бенчмаркали, на ARM7 получили порядка 4.3 миллиона тактов для ч/б 320*240. Это порядка 56 тактов на пиксель.

Ну, я уже устал повторять.. :laughing:

 

Количество "тактов на пиксель" сильно зависит от того, ЧТО изображено в кадре.

Шумоподобный сигнал жмется значительно дольше монотонного..

Если сходить по первой ссылке, то можно убедиться, что количество тактов на пиксель варьируется от 28 до 120, так что все эти сравнения "мочности" - от лукавого..

 

Кстати, а почему Вы соотношение цветное/чб определили как ~1.5? Я бы ориентировался на 2. Хотя... Там же коэффициенты для деления побольше, значит, нулей тоже побольше... Ну да, где-то полтора будет.

Потому, что цвет - 4:2:0, т.е. на каждые четыре пикселя яркости приходится два пикселя цвета.

Так что цветное изображение "в ч/б пикселях" весит в 1,5 раза больше черно-белого изображения таких же размеров..

Изменено 2 июня, 2009 пользователем blackfin

[Rst7 5]

Потому, что цвет - 4:2:0, т.е. на каждые четыре пикселя яркости приходится два пикселя цвета.

 

Да, но имеется две цветовых составляющих. Значит, общее количество точек - двухкратное.

 

Ну, я уже устал повторять..

 

Да знаю я. Но перемножать-то Вы начали ;)

[blackfin 22]

Да, но имеется две цветовых составляющих. Значит, общее количество точек - двухкратное.

Каких точек??

Для цвета 4:2:0 имеем - четыре точки Y, одну точку Cr и одну точку Cb, так что 4+1+1 = 4*1,5.

 

Да знаю я. Но перемножать-то Вы начали ;)

Так это ж, чтобы Мухаммор отстал.. Уж больно настырный..

 

Но ведь, клиент всегда прав?.. :laughing:

Изменено 2 июня, 2009 пользователем blackfin

[Rst7 5]

Сходил по ссылке. Ну в принципе, если ориентироваться на Compression Ratio, то можно забить на то, что нарисованно на картинке. Вот бенчмаркали с результирующим Ratio=9.5. По ссылке такому сжатию соответствуют цифры порядка 45-50 тактов на пиксел.

 

Для цвета 4:2:0 имеем - четыре точки Y, одну точку Cr и одну точку Cb, так что 4+1+1 = 4*1,5.

 

Ах ну да, ну да... Туплю, забыл про y-координату, что там тоже одна точка цвета на две яркостных.