Е, и аз смятам така за спорта
Иначе сериозно се надъхвам да пробвам JPEG на BlackFin-a, да видя как ще се представи, че много го хвалят
Тъкмо ще по разуча самия JPEG алгоритъм.

Благодарско, че ме светна за binDCT-то....

За нищо

ypauns: Tестови картинки да ти се намират BMP to RGB,YUV... или да си правя :)

...

Бравос
И аз нямам тестови картинки, бях почнал да пиша един софт за конвертиране, ама така и него довърших. По принцип за тестове на JPEG имаше някъкви стандартни картинки, мисля че една от тях беше "Мона Лиза"
На каква платформа го изкара този тест?

UYUV 422 to JPEG

Първо го портнах във ИДЕ-то за dsPIC за да тествам скороста, ама симулацията read/write FILE ме изгърбих и минах на Борланд С билдер - и на двете места ще прави едно и също (разлика във скороста само)... оптимизацията после - не съм се спрял на ембедед платформа...

за картинките - намерих разни ама са YUV и немога да видя оригинала
ще напиша на Делфи програмка за конверт само да намеря пропорциите RGB към 444, 420, 422 итн... и съответните структори за запис във фаил


е това в рара е ориг. снимка (168 960 bytes)

Ясно.
Предполагам че и ти си намерил тези формули за преобразуване от

RGB->YCbCr

Y= 0.2989*Red+0.5866*Green+0.1145*Blue
Cb=-0.1687*Red-0.3312*Green+0.5000*Blue
Cr= 0.5000*Red-0.4183*Green-0.0816*Blue

YCbCr->RGB

Red= Y+0.0000*Cb+1.4022*Cr
Green=Y-0.3456*Cb-0.7145*Cr
Blue= Y+1.7710*Cb+0.0000*Cr


Навремето не ми стана много ясно следния монет: имаме примерно 640x480 RGB и обръщаме в YCbCr 420
При него реално се намалява резолюцията на цветовите компоненти на половина преди компресията т.е
Cb , Cr -320x240.
Та при това намаляване на резолюцията просто махат пиксели или се прави осредняване?

това го прави CCDто ама как да го обърна от RGB to 420 и аз са чуда още ама до ден два ще го разбера :)

Не разбрах кое го прави CCD-to?
Иначе за обръщането мисля че така имаш примерно 640x480 24 bit и съгласно формулите
изчисляваш отделните компоненти

Y= 0.2989*Red+0.5866*Green+0.1145*Blue
Cb=-0.1687*Red-0.3312*Green+0.5000*Blue
Cr= 0.5000*Red-0.4183*Green-0.0816*Blue
(Мисля че се вадеше и по 128 от всяка компонента)

В резултат на което имаш Y-640x480, Cb-640x480, Cr-640x480, после правиш "downsampling" на Cb, Cr (все още незнам точния метод) и си готов

това намерих, но несъм го пробвал още

void RGBto420 (unsigned char *rgb, unsigned char *yuv, int width, int
height)
{
int r, g, b, Y1, Cb1, Cr1, Y2, Cb2, Cr2, Y3, Cb3, Cr3, Y4, Cb4, Cr4,
x, y;
for(y = 0; y<height; y += 2)
for(x = 0; x < width; x += 2) {
r = *rgb;
g = *(rgb+1);
b = *(rgb+2);

Y1 = 0.2989 * r + 0.5866 * g + 0.1145 * b;
Cb1 = (b - Y1) / (2. - 2. * 0.1145);
Cr1 = (r - Y1) / (2. - 2. * 0.2989);

r = *(rgb+3);
g = *(rgb+4);
b = *(rgb+5);

Y2 = 0.2989 * r + 0.5866 * g + 0.1145 * b;
Cb2 = (b - Y2) / (2. - 2. * 0.1145);
Cr2 = (r - Y2) / (2. - 2. * 0.2989);

r = *(rgb+3*width);
g = *(rgb+3*width+1);
b = *(rgb+3*width+2);

Y3 = 0.2989 * r + 0.5866 * g + 0.1145 * b;
Cb3 = (b - Y3) / (2. - 2. * 0.1145);
Cr3 = (r - Y3) / (2. - 2. * 0.2989);

r = *(rgb+3*width+3);
g = *(rgb+3*width+4);
b = *(rgb+3*width+5);

Y4 = 0.2989 * r + 0.5866 * g + 0.1145 * b;
Cb4 = (b - Y4) / (2. - 2. * 0.1145);
Cr4 = (r - Y4) / (2. - 2. * 0.2989);

*yuv++ = (unsigned char) Y1 * 219./255/ + 16;
*yuv++ = (unsigned char) Y2 * 219./255/ + 16;
*yuv++ = (unsigned char) Y3 * 219./255/ + 16;
*yuv++ = (unsigned char) Y4 * 219./255/ + 16;
*yuv++ = (unsigned char) (128 + (Cb1 + Cb2 + Cb3 + Cb4) / 4) * 224./255. + 16;
*yuv++ = (unsigned char) (128 + (Cr1 + Cr2 + Cr3 + Cr4) / 4) * 224./255. + 16;

rgb += 6;
}
}

Мисля че ще върши работа, трябва обаче да се оптимизира за целочислена аритметика.

ypauns:

един въпрос за quantization
нали е = DCT[x][y] / quant_table[x][y]

По това което съм чел смятам че е точно така. На практика quantization таблицата определя качеството на
JPEG. При ниското качество (голяма компресия) след quantization повечето от стойностите на DCT са 0