Jpeg 4:2:2 двоится [Решено]
Добавлено: 26.10.2011 16:36:51
Проблема есть RAW изображение в формате YcbCr 4:2:2, необходимо сжать все это дело в Jpeg.
Сжимать bmp или ppm научился и все вроде хорошо, но там формат RGB, скажем вот что получается для этих форматов моим кодером Jpeg.
Качество не очень, просто пока оптика не настроена.
у меня же YСbCr 4:2:2. Если сжимать его то получаю вот такое изображение:
Что меняю для данного формата относительно сжатия bmp:
для bmp было так:
для BMP сжатие проходит в такой последовательности:
для YСbCr 4:2:2
Собственно вопрос: почему может быть такое, что не так?
Просто преобразование в RGB, а потом опять в YСbCr 4:4:4 не айс, нужна скорость. тем более камера дает YСbCr 4:2:2, грех не воспользоваться
PS. Почему нужно программное сжатие, потому что камера не может выдавать маркеры начала и конца кадра для ISI интерфейса AT91SAM9G20 когда камера работает в режиме Jpeg.
PS1. Кодер пишеться под Linux ARM9, поэтому код приведен на Си, ну я думаю тут все прозрачно, и для знающих людей проблема понятна.
Сжимать bmp или ppm научился и все вроде хорошо, но там формат RGB, скажем вот что получается для этих форматов моим кодером Jpeg.
Качество не очень, просто пока оптика не настроена.
у меня же YСbCr 4:2:2. Если сжимать его то получаю вот такое изображение:
Что меняю для данного формата относительно сжатия bmp:
- Код: Выделить всё
static struct SOF0infotype {
WORD marker; // = 0xFFC0
WORD length; // = 17 for a truecolor YCbCr JPG
BYTE precision ;// Should be 8: 8 bits/sample
WORD height ;
WORD width;
BYTE nrofcomponents;//Should be 3: We encode a truecolor JPG
BYTE IdY; // = 1
BYTE HVY; // sampling factors for Y (bit 0-3 vert., 4-7 hor.)
BYTE QTY; // Quantization Table number for Y = 0
BYTE IdCb; // = 2
BYTE HVCb;
BYTE QTCb; // 1
BYTE IdCr; // = 3
BYTE HVCr;
BYTE QTCr; // Normally equal to QTCb = 1
} SOF0info = { 0xFFC0,17,8,0,0,3,1,0x21,0,2,0x11,1,3,0x11,1};
для bmp было так:
- Код: Выделить всё
{0xFFC0,17,8,0,0,3,1,0x11,0,2,0x11,1,3,0x11,1};
для BMP сжатие проходит в такой последовательности:
- Код: Выделить всё
process_DU(Y0DU, fdtbl_Y, &DCY, YDC_HT, YAC_HT); //Y
process_DU(CrDU, fdtbl_Cb, &DCCr, CbDC_HT, CbAC_HT); //Cr
process_DU(CbDU, fdtbl_Cb, &DCCb, CbDC_HT, CbAC_HT); //Cb
для YСbCr 4:2:2
- Код: Выделить всё
process_DU(Y0DU, fdtbl_Y, &DCY, YDC_HT, YAC_HT); //Y0
process_DU(Y1DU, fdtbl_Y, &DCY, YDC_HT, YAC_HT); //Y 1
process_DU(CrDU, fdtbl_Cb, &DCCr, CbDC_HT, CbAC_HT); //Cr
process_DU(CbDU, fdtbl_Cb, &DCCb, CbDC_HT, CbAC_HT); //Cb
Собственно вопрос: почему может быть такое, что не так?
Просто преобразование в RGB, а потом опять в YСbCr 4:4:4 не айс, нужна скорость. тем более камера дает YСbCr 4:2:2, грех не воспользоваться
PS. Почему нужно программное сжатие, потому что камера не может выдавать маркеры начала и конца кадра для ISI интерфейса AT91SAM9G20 когда камера работает в режиме Jpeg.
PS1. Кодер пишеться под Linux ARM9, поэтому код приведен на Си, ну я думаю тут все прозрачно, и для знающих людей проблема понятна.