2011-08-12 154 views
11

PIL v1.1.7使用的算法給出了「被淘汰」的搜索結果。使用ffmpeg轉換相同的源數據時,它看起來是正確的。使用mplayerffmpeg給出了相同的結果(也許它們使用下面的相同庫)。這讓我相信PIL可能會填滿色彩空間的轉換。轉換似乎libImaging/ConvertYCbCr.c進行採購:PIL的顏色空間轉換YCbCr - > RGB

/* JPEG/JFIF YCbCr conversions 

    Y = R * 0.29900 + G * 0.58700 + B * 0.11400 
    Cb = R * -0.16874 + G * -0.33126 + B * 0.50000 + 128 
    Cr = R * 0.50000 + G * -0.41869 + B * -0.08131 + 128 

    R = Y +      + (Cr - 128) * 1.40200 
    G = Y + (Cb - 128) * -0.34414 + (Cr - 128) * -0.71414 
    B = Y + (Cb - 128) * 1.77200 

*/ 

這是在源只是一個評論,當然它的C代碼,實際功能與查找表來實現不矩陣乘法(在static INT16 R_Cr等剪斷爲了簡潔):

void 
ImagingConvertYCbCr2RGB(UINT8* out, const UINT8* in, int pixels) 
{ 
    int x; 
    UINT8 a; 
    int r, g, b; 
    int y, cr, cb; 

    for (x = 0; x < pixels; x++, in += 4, out += 4) { 

     y = in[0]; 
     cb = in[1]; 
     cr = in[2]; 
     a = in[3]; 

     r = y + ((   R_Cr[cr]) >> SCALE); 
     g = y + ((G_Cb[cb] + G_Cr[cr]) >> SCALE); 
     b = y + ((B_Cb[cb]   ) >> SCALE); 

     out[0] = (r <= 0) ? 0 : (r >= 255) ? 255 : r; 
     out[1] = (g <= 0) ? 0 : (g >= 255) ? 255 : g; 
     out[2] = (b <= 0) ? 0 : (b >= 255) ? 255 : b; 
     out[3] = a; 
    } 
} 

我已經google了,但似乎有很多關於'正確'的方式來做這種顏色空間轉換的困惑。所以我的問題是,上述是否正確 - 如果不是更好的方法?


編輯:讀馬克贖金提供的鏈接後,我發現,矛盾的定義存在取決於你是否使用全套的YCbCr或鉗出到有效範圍。見下面鏈接,瞭解更多信息:

看來PIL版本使用不正確的算法,所以我推出我自己的功能,其給出正確的轉換預期結果(「SDTV」版本)。下面的代碼包括,爲未來的讀者使用:

from numpy import dot, ndarray, array 

def yuv2rgb(im, version='SDTV'): 
    """ 
    Convert array-like YUV image to RGB colourspace 

    version: 
     - 'SDTV': ITU-R BT.601 version (default) 
     - 'HDTV': ITU-R BT.709 version 
    """ 
    if not im.dtype == 'uint8': 
     raise TypeError('yuv2rgb only implemented for uint8 arrays') 

    # clip input to the valid range 
    yuv = ndarray(im.shape) # float64 
    yuv[:,:, 0] = im[:,:, 0].clip(16, 235).astype(yuv.dtype) - 16 
    yuv[:,:,1:] = im[:,:,1:].clip(16, 240).astype(yuv.dtype) - 128 

    if version.upper() == 'SDTV': 
     A = array([[1.,     0., 0.701   ], 
        [1., -0.886*0.114/0.587, -0.701*0.299/0.587], 
        [1., 0.886,        0.]]) 
     A[:,0] *= 255./219. 
     A[:,1:] *= 255./112. 
    elif version.upper() == 'HDTV': 
     A = array([[1.164,  0., 1.793], 
        [1.164, -0.213, -0.533], 
        [1.164, 2.112,  0.]]) 
    else: 
     raise Exception("Unrecognised version (choose 'SDTV' or 'HDTV')") 

    rgb = dot(yuv, A.T) 
    result = rgb.clip(0, 255).astype('uint8') 

    return result 
+1

它與http://en.wikipedia.org/wiki/YCbCr上的機制之一相匹配嗎? –

回答

7

如果你看一下維基百科的定義,你可以看到有針對的YCbCr兩種相互衝突的定義。 ITU-R BT.601定義將值壓縮到16-235範圍以提供足部空間和淨空,而JPEG版本使用全範圍0-255。如果您要使用JPEG的公式解碼BT.601空間中的值,結果肯定會被淘汰。

+1

謝謝,這讓我走上了正軌,我在這裏發現了各種標準(oxymoron?)的明確解釋 - > http://www.equasys.de/colorconversion.html – wim