Manhoso 0 27 мая, 2009 Опубликовано 27 мая, 2009 · Жалоба Где раздобыть программные библиотеки для реализации алгоритма JPEG? Изображение 720х480, 10 бит на пиксель, процессор BF561. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 25 27 мая, 2009 Опубликовано 27 мая, 2009 · Жалоба JPEG Encoder JPEG Decoder Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Manhoso 0 27 мая, 2009 Опубликовано 27 мая, 2009 · Жалоба Эспасибо. А скачать как? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 25 27 мая, 2009 Опубликовано 27 мая, 2009 · Жалоба Там ссылка внизу страницы, кроме того: You must register or log in to download Software Development Kits (SDKs) and Software Modules: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Manhoso 0 27 мая, 2009 Опубликовано 27 мая, 2009 · Жалоба Тьфуты, точно. Спасибо большое. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Manhoso 0 2 июня, 2009 Опубликовано 2 июня, 2009 (изменено) · Жалоба В общем, скачал себе библиотеку, закинул куда нужно, в опциях линкера прописал название и путь к ней - а при компиляции проекта, который использует функции библиотеки 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 2 июня, 2009 Опубликовано 2 июня, 2009 · Жалоба Ну тогда какое минимально возможное время преобразования ч/б изображения 720х480 на BF561 при 600 МГц? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 25 2 июня, 2009 Опубликовано 2 июня, 2009 (изменено) · Жалоба Минимально возможное время - один такт DSP = 1/600 uS. За это время время любое изображение можно сжать в файл размером в один байт. А если серьезно, то время сжатия зависит от полной вариации исходного изображения, выбранных таблиц Гаффмана и значений коэффициентов квантователя.. Изменено 2 июня, 2009 пользователем blackfin Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Manhoso 0 2 июня, 2009 Опубликовано 2 июня, 2009 · Жалоба Мне, чтоб получить выигрыш, необходимо, чтоб проц ужимал картинку за 30 мс. Это реально? Все-таки, чего компилятор ругается? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 25 2 июня, 2009 Опубликовано 2 июня, 2009 · Жалоба Мне, чтоб получить выигрыш, необходимо, чтоб проц ужимал картинку за 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 2 июня, 2009 Опубликовано 2 июня, 2009 · Жалоба 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 25 2 июня, 2009 Опубликовано 2 июня, 2009 (изменено) · Жалоба Какие-то странные цифры. Помните, когда мой кодер бенчмаркали, на ARM7 получили порядка 4.3 миллиона тактов для ч/б 320*240. Это порядка 56 тактов на пиксель. Ну, я уже устал повторять.. :laughing: Количество "тактов на пиксель" сильно зависит от того, ЧТО изображено в кадре. Шумоподобный сигнал жмется значительно дольше монотонного.. Если сходить по первой ссылке, то можно убедиться, что количество тактов на пиксель варьируется от 28 до 120, так что все эти сравнения "мочности" - от лукавого.. Кстати, а почему Вы соотношение цветное/чб определили как ~1.5? Я бы ориентировался на 2. Хотя... Там же коэффициенты для деления побольше, значит, нулей тоже побольше... Ну да, где-то полтора будет. Потому, что цвет - 4:2:0, т.е. на каждые четыре пикселя яркости приходится два пикселя цвета. Так что цветное изображение "в ч/б пикселях" весит в 1,5 раза больше черно-белого изображения таких же размеров.. Изменено 2 июня, 2009 пользователем blackfin Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 2 июня, 2009 Опубликовано 2 июня, 2009 · Жалоба Потому, что цвет - 4:2:0, т.е. на каждые четыре пикселя яркости приходится два пикселя цвета. Да, но имеется две цветовых составляющих. Значит, общее количество точек - двухкратное. Ну, я уже устал повторять.. Да знаю я. Но перемножать-то Вы начали ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 25 2 июня, 2009 Опубликовано 2 июня, 2009 (изменено) · Жалоба Да, но имеется две цветовых составляющих. Значит, общее количество точек - двухкратное. Каких точек?? Для цвета 4:2:0 имеем - четыре точки Y, одну точку Cr и одну точку Cb, так что 4+1+1 = 4*1,5. Да знаю я. Но перемножать-то Вы начали ;) Так это ж, чтобы Мухаммор отстал.. Уж больно настырный.. Но ведь, клиент всегда прав?.. :laughing: Изменено 2 июня, 2009 пользователем blackfin Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 2 июня, 2009 Опубликовано 2 июня, 2009 · Жалоба Сходил по ссылке. Ну в принципе, если ориентироваться на Compression Ratio, то можно забить на то, что нарисованно на картинке. Вот бенчмаркали с результирующим Ratio=9.5. По ссылке такому сжатию соответствуют цифры порядка 45-50 тактов на пиксел. Для цвета 4:2:0 имеем - четыре точки Y, одну точку Cr и одну точку Cb, так что 4+1+1 = 4*1,5. Ах ну да, ну да... Туплю, забыл про y-координату, что там тоже одна точка цвета на две яркостных. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться