Някой да срещал интересни сорс решения, но не за "бавен ембедед Линукс"...

Основния open source за JPEG, който съм виждал е на Independent JPEG Group's software. Главния изчислителен ресурс при JPEG e за DCT-алгоритъма. Навремето бях свалял разни статии, където правеха DCT, без умножение а само с разни ротации и прочее и увеличават бързодейсвието,но трябва да се разровя да ги намеря. Всъщност незнам точно какво имаш предвид по интересни?

е точно това търся :)

ОК. Ще ми трябва малко време да ги изровя. Мисля че в тях обаче няма готов сорс, имаше доста математика имаше и разни сравнения по отношение на бързодействието. Значи отворения код за JPEG, за който писах в предния пост има опция за компилация при която се ползва доста оптимизиран алгоритъм за DCT и работи с целочислена аритметика. Всъщност въпроса е на каква платоформа искаш да го пускаш. Аз лично като имам малко време мисля да пробвам да го портна за BlackFin на АD.

на 16 битова РИСК платформа
искам да тествам на 40 мипса (Инфинеон XC167)
гоня над 4 фрейма в секунда
В монента не пиша нищо по въпроса, а събирам инфо относно JPEG-a

Смъкни си eCos, там имаше някакава JPEG релизация май, и си е готов код.

На 40MIPS-a, наистина ще ти трябва добра оптимизация. В документите дето изрових има пример за ARM на 400MHz, който постига 7 кадъра в секунда при 512x512-24bits/pixel, тествете са правени по Linux. По повечето фотоапарати и web-камерки ползват хардуерни кодеци. Всъщност гледал съм при евтините web-камери, ползват чип който постига 15f/s при 320x240, само че изхода е USB-stream. Иначе събрах статтиите -архива е 6MB, ако те интересуват може да ти ги пратя. Има и разни примерни кодове вътре.

Най-отгоре съм написал без Linux решения...

Незнам, имам наблюдения над китайски изработки на 54 мипса (х86) и постигат 8 фрейма/сек 640/480 без хардуерни кодеци.

Всъщност прав си за Linux-a, ония пичове с ARM-a сигурно са взели готвия отворен код и са го компилирали без особени оптимизации. Щом китайците имат решения може и да стане, но сигурно ще иска сериозно ръчкане за да се изтискат максимални резултати от процесора. Между другото метода за DCT, без умножение за който писах по-горе се нарича binDCT, казват че процесори които не могат да умножават бързо оказва сериозно подобрение върху бързодействието.

има нещо глило :)) .......

оптимизацията за 1Д май се свежда до:

a is "addition"
s is "substraction"
m is "multiply"

aassaassasaasaamasmmmmasasaasasaas по 8 пъти

малиии бая мислене ще пада......
ще събера повече инфо и ще пробвам :)

ypauns
тествах 2 метода за DCT 2D:

Embeded: със integer - addition, substraction и multiply
И
Linux: float - addition, substraction, multiply, cos и sqrt

относителната разликата е приблизително 1 мили към 4
мразим Linux :))

Незнам дали е виновен Linux-a, но по принцип с "float" аритметика е по-бавно. Виж какви резултати дават
тук в една статия за различните методи. Платформата е PIII 550MHz, ОС твоя "любим" Линукс:

EXECUTING TIMES OF DIFFERENT DCT’s FOR A 8x8 IMAGE BLOCK

IJG Floating DCT - 119.05us
IJG Integer DCT - 4.10us
IJG Fast Int. - 2.39us
binDCT-C1 - 2.45us
binDCT-C4 - 2.09us
binDCT-C7 - 2.06us

IJG - Independent JPEG group - open source

да, намерих инфото за binDCT :)

Test:
dsPIC 40 mipsa
block pixel 8x8

full float = 4 sec
DCT = 360 uSec
binDCT = 118 uSec

експеримента продължава :)

Значи при 640x480 -имаме 4800 блкочета 8x8 x 119us =0.57 sec и то само за Y-компонета и без другите кодирания.
Очевидно на dsPIC, ще му трябват секунди за да направи цялата компресия.

има нещо такова но не съм оптимизирал процеса за dsPIC
аритметиката на теста е инт32 а пика е 16 битов, а и гледам че има бая шифтове дето бават, може да ги преправя на умножение
а и не гледай че си играя с пика - просто ползвам идето за симулация... не съм почнал поект - спортна злоба :)