yuv rgb 互轉 公式 及演算法
1 前言
自然界的顏色千變萬化,為了給顏色一個量化的衡量標準,就需要建立色彩空間模型來描述各種各樣的顏色,由於人對色彩的感知是一個複雜的生理和心理聯合作用的過程,所以在不同的應用領域中為了更好更準確的滿足各自的需求,就出現了各種各樣的色彩空間模型來量化的描述顏色。我們比較常接觸到的就包括 RGB / CMYK / YIQ / YUV / HSI等等。
對於數位電子多媒體領域來說,我們經常接觸到的色彩空間的概念,主要是RGB , YUV這兩種(實際上,這兩種體系包含了許多種具體的顏色表達方式和模型,如sRGB, Adobe RGB, YUV422, YUV420 …), RGB是按三基色加光系統的原理來描述顏色,而YUV則是按照 亮度,色差的原理來描述顏色。
即使只是RGB YUV這兩大類色彩空間,所涉及到的知識也是十分豐富複雜的,自知不具備足夠的相關專業知識,所以本文主要針對工程領域的應用及演算法進行討論。
2 YUV相關色彩空間模型
2.1 YUV 與 YIQ YcrCb
對於YUV模型,實際上很多時候,我們是把它和YIQ / YCrCb模型混為一談的。
實際上,YUV模型用於PAL制式的電視系統,Y表示亮度,UV並非任何單詞的縮寫。
YIQ模型與YUV模型類似,用於NTSC制式的電視系統。YIQ顏色空間中的I和Q分量相當於將YUV空間中的UV分量做了一個33度的旋轉。
YCbCr顏色空間是由YUV顏色空間派生的一種顏色空間,主要用於數字電視系統中。從RGB到YCbCr的轉換中,輸入、輸出都是8位二進位制格式。
三者與RGB的轉換方程如下:
RGB -> YUV:
實際上也就是:
Y=0.30R+0.59G+0.11B , U=0.493(B-Y) , V=0.877(R-Y)
RGB -> YIQ:
RGB -> YCrCb:
從公式中,我們關鍵要理解的一點是,UV / CbCr訊號實際上就是藍色差訊號和紅色差訊號,進而言之,實際上一定程度上間接的代表了藍色和紅色的強度,理解這一點對於我們理解各種顏色變換處理的過程會有很大的幫助。
我們在數位電子多媒體領域所談到的YUV格式,實際上準確的說,是以YcrCb色彩空間模型為基礎的具有多種儲存格式的一類顏色模型的家族(包括YUV444 / YUV422 / YUV420 / YUV420P等等)。並不是傳統意義上用於PAL制模擬電視的YUV模型。這些YUV模型的區別主要在於UV資料的取樣方式和儲存方式,這裡就不詳述。
而在Camera Sensor中,最常用的YUV模型是 YUV422格式,因為它採用4個位元組描述兩個畫素,能和RGB565模型比較好的相容。有利於Camera Sensor和Camera controller的軟硬體介面設計。
3 YUV2RGB快速演算法分析
這裡指的YUV實際是YcrCb了,YUV2RGB的轉換公式本身是很簡單的,但是牽涉到浮點運算,所以,如果要實現快速演算法,演算法結構本身沒什麼好研究的了,主要是採用整型運算或者查表來加快計算速度。
首先可以推導得到轉換公式為:
R = Y + 1.4075 *(V-128)
G = Y – 0.3455 *(U –128) – 0.7169 *(V –128)
B = Y + 1.779 *(U – 128)
3.1 整型演算法
要用整型運算代替浮點運算,當然是要用移位的辦法了,我們可以很容易得到下列演算法:
u = YUVdata[UPOS] - 128;
v = YUVdata[VPOS] - 128;
rdif = v + ((v * 103) >> 8);
invgdif = ((u * 88) >> 8) +((v * 183) >> 8);
bdif = u +( (u*198) >> 8);
r = YUVdata[YPOS] + rdif;
g = YUVdata[YPOS] - invgdif;
b = YUVdata[YPOS] + bdif;
為了防止出現溢位,還需要判錯計算的結果是否在0-255範圍內,做類似下面的判斷。
if (r>255)
r=255;
if (r<0)
r=0;
要從RGB24轉換成RGB565資料還要做移位和或運算:
RGBdata[1] =( (r & 0xF8) | ( g >> 5) );
RGBdata[0] =( ((g & 0x1C) << 3) | ( b >> 3) );
3.2 部分查表法
查表法首先可以想到的就是用查表替代上述整型演算法中的乘法運算。
rdif = fac_1_4075[u];
invgdif = fac_m_0_3455[u] + fac_m_0_7169[v];
bdif = fac_1_779[u];
這裡一共需要4個1維陣列,下標從0開始到255,表格共佔用約1K的記憶體空間。uv可以不需要做減128的操作了。在事先計算對應的陣列元素的值的時候計算在內就好了。
對於每個畫素,部分查表法用查表替代了2次減法運算和4次乘法運算,4次移位運算。但是,依然需要多次加法運算和6次比較運算和可能存在的賦值操作,相對第一種方法運算速度提高並不明顯。
3.3 完全查表法
那麼是否可以由YUV直接查表得到對應的RGB值呢?乍一看似乎不太可能,以最複雜的G的運算為例,因為G與YUV三者都相關,所以類似 G=YUV2G[Y][U][V]這樣的演算法,一個三維下標尺寸都為256的陣列就需要佔用2的24次方約16兆空間,絕對是沒法接受的。所以目前多數都是採用部分查表法。
但是,如果我們仔細分析就可以發現,對於G我們實際上完全沒有必要採用三維陣列,因為Y只與UV運算的結果相關,與UV的個體無關,所以我們可以採用二次查表的方法將G的運算簡化為對兩個二維陣列的查表操作,如下:
G = yig2g_table[ y ][ uv2ig_table[ u ][ v ] ];
而RB本身就只和YU或YV相關,所以這樣我們一共需要4個8*8的二維表格,需要佔用4乘2的16次方共256K記憶體。基本可以接受。但是對於手機這樣的嵌入式運用來說,還是略有些大了。
進一步分析,我們可以看到,因為在手機等嵌入式運用上我們最終是要把資料轉換成RGB565格式送到LCD屏上顯示的,所以,對於RGB三分量來說,我們根本不需要8bit這麼高的精度,為了簡單和運算的統一起見,對每個分量我們其實只需要高6bit的資料就足夠了,所以我們可以進一步把表格改為4個6*6的二維表格,這樣一共只需要佔用16K記憶體!在計算表格元素值的時候還可以把最終的溢位判斷也事先做完。最後的演算法如下:
y = (YUVdata[Y1POS] >> 2);
u = (YUVdata[UPOS] >> 2);
v = (YUVdata[VPOS] >> 2);
r = yv2r_table[ y ][ v ];
g = yig2g_table[ y ][ uv2ig_table[ u ][ v ] ];
b = yu2b_table[ y ][ u ];
RGBdata[1] =( (r & 0xF8) | ( g >> 5) );
RGBdata[0] =( ((g & 0x1C) << 3) | ( b >> 3) );
這樣相對部分查表法,我們增加了3次移位運算,而進一步減少了4次加法運算和6次比較賦值操作。
在計算表格元素數值的時候,要考慮舍入和偏移等因數使得計算的中間結果滿足陣列下標非負的要求,需要一定的技巧。
採用完全查表法,相對於第一種演算法,最終運算速度可以有比較明顯的提高,具體效能能提高多少,要看所在平臺的CPU運算速度和記憶體存取速度的相對比例。記憶體存取速度越快,用查表法帶來的效能改善越明顯。在我的PC上測試的結果效能大約能提高35%。而在某ARM平臺上測試只提高了約15%。
3.4 進一步的思考
實際上,上述演算法:
RGBdata[1] =( (r & 0xF8) | ( g >> 5) );
RGBdata[0] =( ((g & 0x1C) << 3) | ( b >> 3) );
中的 (r & 0xF8) 和 ( b >> 3) 等運算也完全可以在表格中事先計算出來。另外,YU / YV的取值實際上不可能覆蓋滿6*6的範圍,中間有些點是永遠取不到的無輸入,RB的運算也可以考慮用5*5的表格。這些都可能進一步提高運算的速度,減小表格的尺寸。
另外,在嵌入式運用中,如果可能儘量將表格放在高速記憶體如SRAM中應該比放在SDRAM中更加能發揮查表法的優勢。
4 RGB2YUV ?
目前覺得這個是沒法將3維表格的查表運算化簡為2維表格的查表運算了。只能用部分查表法替代其中的乘法運算。
另外,多數情況下,我們需要的還是YUV2RGB的轉換,因為從Sensor得到的資料通常我們會用YUV資料,此外JPG和MPEG實際上也是基於YUV格式編碼的,所以要顯示解碼後的資料需要的也是YUV2RGB的運算。 以下是從DirectShow中摘抄的相關文章計算機彩色顯示器顯示色彩的原理與彩色電視機一樣,都是採用R(Red)、G(Green)、B(Blue)相加混色的原理:通過發射出三種不同強度的電子束,使螢幕內側覆蓋的紅、綠、藍磷光材料發光而產生色彩。這種色彩的表示方法稱為RGB色彩空間表示(它也是多媒體計算機技術中用得最多的一種色彩空間表示方法)。
根據三基色原理,任意一種色光F都可以用不同分量的R、G、B三色相加混合而成。
F = r [ R ] + g [ G ] + b [ B ]
其中,r、g、b分別為三基色參與混合的係數。當三基色分量都為0(最弱)時混合為黑色光;而當三基色分量都為k(最強)時混合為白色光。調整r、g、b三個係數的值,可以混合出介於黑色光和白色光之間的各種各樣的色光。
那麼YUV又從何而來呢?在現代彩色電視系統中,通常採用三管彩色攝像機或彩色CCD攝像機進行攝像,然後把攝得的彩色影象訊號經分色、分別放大校正後得到RGB,再經過矩陣變換電路得到亮度訊號Y和兩個色差訊號R-Y(即U)、B-Y(即V),最後傳送端將亮度和色差三個訊號分別進行編碼,用同一通道傳送出去。這種色彩的表示方法就是所謂的YUV色彩空間表示。
採用YUV色彩空間的重要性是它的亮度訊號Y和色度訊號U、V是分離的。如果只有Y訊號分量而沒有U、V分量,那麼這樣表示的影象就是黑白灰度影象。彩色電視採用YUV空間正是為了用亮度訊號Y解決彩色電視機與黑白電視機的相容問題,使黑白電視機也能接收彩色電視訊號。
YUV與RGB相互轉換的公式如下(RGB取值範圍均為0-255):
Y = 0.299R + 0.587G + 0.114B
U = -0.147R - 0.289G + 0.436B
V = 0.615R - 0.515G - 0.100B
R = Y + 1.14V
G = Y - 0.39U - 0.58V
B = Y + 2.03U
在DirectShow中,常見的RGB格式有RGB1、RGB4、RGB8、RGB565、RGB555、RGB24、RGB32、ARGB32等;常見的YUV格式有YUY2、YUYV、YVYU、UYVY、AYUV、Y41P、Y411、Y211、IF09、IYUV、YV12、YVU9、YUV411、YUV420等。作為視訊媒體型別的輔助說明型別(Subtype),它們對應的GUID見表2.3。
表2.3 常見的RGB和YUV格式
GUID 格式描述
MEDIASUBTYPE_RGB1 2色,每個畫素用1位表示,需要調色盤
MEDIASUBTYPE_RGB4 16色,每個畫素用4位表示,需要調色盤
MEDIASUBTYPE_RGB8 256色,每個畫素用8位表示,需要調色盤
MEDIASUBTYPE_RGB565 每個畫素用16位表示,RGB分量分別使用5位、6位、5位
MEDIASUBTYPE_RGB555 每個畫素用16位表示,RGB分量都使用5位(剩下的1位不用)
MEDIASUBTYPE_RGB24 每個畫素用24位表示,RGB分量各使用8位
MEDIASUBTYPE_RGB32 每個畫素用32位表示,RGB分量各使用8位(剩下的8位不用)
MEDIASUBTYPE_ARGB32 每個畫素用32位表示,RGB分量各使用8位(剩下的8位用於表示Alpha通道值)
MEDIASUBTYPE_YUY2 YUY2格式,以4:2:2方式打包
MEDIASUBTYPE_YUYV YUYV格式(實際格式與YUY2相同)
MEDIASUBTYPE_YVYU YVYU格式,以4:2:2方式打包
MEDIASUBTYPE_UYVY UYVY格式,以4:2:2方式打包
MEDIASUBTYPE_AYUV 帶Alpha通道的4:4:4 YUV格式
MEDIASUBTYPE_Y41P Y41P格式,以4:1:1方式打包
MEDIASUBTYPE_Y411 Y411格式(實際格式與Y41P相同)
MEDIASUBTYPE_Y211 Y211格式
MEDIASUBTYPE_IF09 IF09格式
MEDIASUBTYPE_IYUV IYUV格式
MEDIASUBTYPE_YV12 YV12格式
MEDIASUBTYPE_YVU9 YVU9格式
下面分別介紹各種RGB格式。
¨ RGB1、RGB4、RGB8都是調色盤型別的RGB格式,在描述這些媒體型別的格式細節時,通常會在BITMAPINFOHEADER資料結構後面跟著一個調色盤(定義一系列顏色)。它們的影象資料並不是真正的顏色值,而是當前畫素顏色值在調色盤中的索引。以RGB1(2色點陣圖)為例,比如它的調色盤中定義的兩種顏色值依次為0x000000(黑色)和0xFFFFFF(白色),那麼影象資料001101010111…(每個畫素用1位表示)表示對應各畫素的顏色為:黑黑白白黑白黑白黑白白白…。
¨ RGB565使用16位表示一個畫素,這16位中的5位用於R,6位用於G,5位用於B。程式中通常使用一個字(WORD,一個字等於兩個位元組)來操作一個畫素。當讀出一個畫素後,這個字的各個位意義如下:
高位元組 低位元組
R R R R R G G G G G G B B B B B
可以組合使用遮蔽字和移位操作來得到RGB各分量的值:
#define RGB565_MASK_RED 0xF800
#define RGB565_MASK_GREEN 0x07E0
#define RGB565_MASK_BLUE 0x001F
R = (wPixel & RGB565_MASK_RED) >> 11; // 取值範圍0-31
G = (wPixel & RGB565_MASK_GREEN) >> 5; // 取值範圍0-63
B = wPixel & RGB565_MASK_BLUE; // 取值範圍0-31
¨ RGB555是另一種16位的RGB格式,RGB分量都用5位表示(剩下的1位不用)。使用一個字讀出一個畫素後,這個字的各個位意義如下:
高位元組 低位元組
X R R R R G G G G G B B B B B (X表示不用,可以忽略)
可以組合使用遮蔽字和移位操作來得到RGB各分量的值:
#define RGB555_MASK_RED 0x7C00
#define RGB555_MASK_GREEN 0x03E0
#define RGB555_MASK_BLUE 0x001F
R = (wPixel & RGB555_MASK_RED) >> 10; // 取值範圍0-31
G = (wPixel & RGB555_MASK_GREEN) >> 5; // 取值範圍0-31
B = wPixel & RGB555_MASK_BLUE; // 取值範圍0-31
¨ RGB24使用24位來表示一個畫素,RGB分量都用8位表示,取值範圍為0-255。注意在記憶體中RGB各分量的排列順序為:BGR BGR BGR…。通常可以使用RGBTRIPLE資料結構來操作一個畫素,它的定義為:
typedef struct tagRGBTRIPLE {
BYTE rgbtBlue; // 藍色分量
BYTE rgbtGreen; // 綠色分量
BYTE rgbtRed; // 紅色分量
} RGBTRIPLE;
¨ RGB32使用32位來表示一個畫素,RGB分量各用去8位,剩下的8位用作Alpha通道或者不用。(ARGB32就是帶Alpha通道的RGB32。)注意在記憶體中RGB各分量的排列順序為:BGRA BGRA BGRA…。通常可以使用RGBQUAD資料結構來操作一個畫素,它的定義為:
typedef struct tagRGBQUAD {
BYTE rgbBlue; // 藍色分量
BYTE rgbGreen; // 綠色分量
BYTE rgbRed; // 紅色分量
BYTE rgbReserved; // 保留位元組(用作Alpha通道或忽略)
} RGBQUAD;
下面介紹各種YUV格式。YUV格式通常有兩大類:打包(packed)格式和平面(planar)格式。前者將YUV分量存放在同一個陣列中,通常是幾個相鄰的畫素組成一個巨集畫素(macro-pixel);而後者使用三個陣列分開存放YUV三個分量,就像是一個三維平面一樣。表2.3中的YUY2到Y211都是打包格式,而IF09到YVU9都是平面格式。(注意:在介紹各種具體格式時,YUV各分量都會帶有下標,如Y0、U0、V0表示第一個畫素的YUV分量,Y1、U1、V1表示第二個畫素的YUV分量,以此類推。)
¨ YUY2(和YUYV)格式為每個畫素保留Y分量,而UV分量在水平方向上每兩個畫素取樣一次。一個巨集畫素為4個位元組,實際表示2個畫素。(4:2:2的意思為一個巨集畫素中有4個Y分量、2個U分量和2個V分量。)影象資料中YUV分量排列順序如下:
Y0 U0 Y1 V0 Y2 U2 Y3 V2 …
¨ YVYU格式跟YUY2類似,只是影象資料中YUV分量的排列順序有所不同:
Y0 V0 Y1 U0 Y2 V2 Y3 U2 …
¨ UYVY格式跟YUY2類似,只是影象資料中YUV分量的排列順序有所不同:
U0 Y0 V0 Y1 U2 Y2 V2 Y3 …
¨ AYUV格式帶有一個Alpha通道,並且為每個畫素都提取YUV分量,影象資料格式如下:
A0 Y0 U0 V0 A1 Y1 U1 V1 …
¨ Y41P(和Y411)格式為每個畫素保留Y分量,而UV分量在水平方向上每4個畫素取樣一次。一個巨集畫素為12個位元組,實際表示8個畫素。影象資料中YUV分量排列順序如下:
U0 Y0 V0 Y1 U4 Y2 V4 Y3 Y4 Y5 Y6 Y8 …
¨ Y211格式在水平方向上Y分量每2個畫素取樣一次,而UV分量每4個畫素取樣一次。一個巨集畫素為4個位元組,實際表示4個畫素。影象資料中YUV分量排列順序如下:
Y0 U0 Y2 V0 Y4 U4 Y6 V4 …
¨ YVU9格式為每個畫素都提取Y分量,而在UV分量的提取時,首先將影象分成若干個4 x 4的巨集塊,然後每個巨集塊提取一個U分量和一個V分量。影象資料儲存時,首先是整幅影象的Y分量陣列,然後就跟著U分量陣列,以及V分量陣列。IF09格式與YVU9類似。
¨ IYUV格式為每個畫素都提取Y分量,而在UV分量的提取時,首先將影象分成若干個2 x 2的巨集塊,然後每個巨集塊提取一個U分量和一個V分量。YV12格式與IYUV類似。
¨ YUV411、YUV420格式多見於DV資料中,前者用於NTSC制,後者用於PAL制。YUV411為每個畫素都提取Y分量,而UV分量在水平方向上每4個畫素取樣一次。YUV420並非V分量取樣為0,而是跟YUV411相比,在水平方向上提高一倍色差取樣頻率,在垂直方向上以U/V間隔的方式減小一半色差取樣,如圖2.12所示.
相關推薦
yuv rgb 互轉 公式 及演算法
1 前言 自然界的顏色千變萬化,為了給顏色一個量化的衡量標準,就需要建立色彩空間模型來描述各種各樣的顏色,由於人對色彩的感知是一個複雜的生理和心理聯合作用的過程,所以在不同的應用領域中為了更好更準確的滿足各自的需求,就出現了各種各樣的色彩空間模型來量化的描述顏色。我們比較常接觸到的就包括
YUV與RGB互轉各種公式 (YUV與RGB的轉換公式有很多種,請注意區別!!!)
一、 公式:基於BT.601-6 BT601 UV 的座標圖(量化後): (橫座標為u,縱座標為v,左下角為原點) 通過座標圖我們可以看到UV並不會包含整個座標系,而是呈一個旋轉了一
不同格式的YUV 和 RGB互轉
YUV色彩空間: Y是亮度值,也就是說8位的灰度值即可組成一幅黑白影象,黑白電視機就是這樣的. UV是色彩值,是給Y上色用的.U是Cb也就是RGB中的藍色分量,V是Cr也就是RGB中的紅色分量. YUV444 指的是每四個畫素取樣中每個亮度Y分量都有一個色彩UV分
【實用簡單】色彩空間互轉:LAB與RGB互轉,RGB與HSI互轉
以下公式皆可直接使用,沒有原理介紹!!! 目錄 LAB與RGB公式互轉 RGB -> Lab空間 Lab空間-> RGB空間 RGB與HSI公式互轉 RGB-> HSI空間 HSI空間->RGB 空間 LAB與RGB公式互轉 RGB
CMYK與RGB引數轉換公式及轉換方法
1. RGB色彩模式 自然界中絕大部分的可見光譜可以用紅、綠和藍三色光按不同比例和強度的混合來表示。RGB分別代表著3種顏色:R代表紅色,G代表綠色、B代表藍色。RGB模型也稱為加色模型,如圖5所示。RGB模型通常用於光照、視訊和螢幕影象編輯。 RGB色彩模式使用RGB模型為影象中每一個畫素的RGB分量分
YUV 格式與 RGB 格式的相互轉換公式及C++ 程式碼
YUV 格式與 RGB 格式的相互轉換公式 最近在用的一個工業相機,輸出的影象格式是 YUY2 格式。而在電腦上顯示時需要 RGB 格式,所以就花了些時間在網上查了些相關的資料。說實話,網上關於 YUV 與 RGB 格式變換的文章挺多的,本來不需要我再多寫這麼
RGB與HSV之間的轉換公式及顏色表
bsp 公式 blog log b- size 分享 ont idt RGB & HSV 英文全稱 RGB - Red, Green, Blue HSV - Hue, Saturation, Value HSV --> RGB 轉換公式 HSV --&g
javascript中json對象json數組json字符串互轉及取值
圖片 今天 too 部門 scrip asc name spa code 今天用到了json數組和json對象和json類型字符串之間互轉及取值,記錄一下: 1.json類型的字符串轉換為json對象及取值 1 var jsonString = ‘{"bar":"pr
YUV和RGB調節色彩公式
1.YUV調節色彩公式(必須是量化後的YUV(16-235)),非量化後的YUV轉換有問題。 轉換公式為: 原始YUV(Y,U,V),轉換後YUV(Y',U',V'),亮度 :g_Bright (0-1),飽和度:g_Saturation(0-1),對比度:g_Contrast (0-1
中綴表示式與字尾表示式之間的互轉及求值
中綴表示式:常見的運算表示式,如(3+4)×5-6 字首表示式又稱波蘭式:運算子位於運算元之前,比如:- × + 3 4 5 6 字尾表示式又稱逆波蘭表示式:與字首表示式相似,只是運算子位於運算元之後,如:3 4 + 5 × 6 - 中綴表示式轉字尾表示式
用c++實現顏色空間rgb,grey,luv和lab的互轉
1 rgb轉grey,rgb轉luv,rgb轉lab 1. 1 rgb轉grey void RgbToGrey(unsigned char *rgb, double *grey) { double R = ((dou
Python中rgb與ycbcr互轉
mat = np.array( [[ 65.481, 128.553, 24.966 ], [-37.797, -74.203, 112.0 ], [ 112.0, -9
FFmpeg 將YUV數據轉RGB
分配內存 () alloc idt img yuv420 init() 復制 ext void init() //分配兩個Frame,兩段buff,一個轉換上下文 { //為每幀圖像分配內存 m_pFrameYUV = av_frame_alloc();
java中駝峰與下橫線格式字串互轉演算法
public static final char UNDERLINE = '_'; /** * 駝峰格式字串轉換為下劃線格式字串 * * @param param * @return */ public s
Python實現RGB和Lab顏色空間互轉
在網上找了一圈,只找到C++版本的,有個python版本的只有RGB轉Lab,只好自己寫了。C++版本傳送門,這裡把原理已經寫的很清楚了,我只是比葫蘆畫瓢的寫個python版本,沒做任何優化。只有一點需要小心,opencv讀取的影象格式是[b,g,r],剩下的就
最小生成樹(MST)的性質及演算法 [轉】
轉自: 最小生成樹性質1:設G=(V,E)是一個連通網路,U是頂點集V的一個真子集。若(u,v)是G中所有的一個端點在U(u∈U)裡、另一個端點不在U(即v∈V-U)裡的邊中,具有最小權值的一條邊,則一定存在G的一棵最小生成樹包括此邊(u,v)。 證明: 為方便說明
轉:MySQL索引背後的資料結構及演算法原理
@rover這個是C++模板 --胡滿超 stack<Postion> path__;這個裡面 ”<> “符號是什麼意思?我在C++語言裡面沒見過呢? 初學者,大神勿噴。
Office word中mathtype公式與LaTex公式程式碼互轉
在word中,輸入好的mathtype公式已經嵌入到word內容中了,如何轉成LaTex公式程式碼呢? 很簡單,mathtype已經內建了相關功能和快捷鍵,按鈕在word中【MathType】-【Publish】-【Toggle Tex】,其快捷鍵為Alt+\,實現math
Java中文編碼及各種編碼互轉和Java判斷檔案編碼
Unicode UTF-8 GBK 及一點Java程式碼 Unicode UTF-8 GBK這些不同的編碼,我們可以想象為不同的字典。同一個漢字,在不同的字典裡面,我們用不同的編號儲存。比如漢字"陳"在Unicode裡編號為9648,在GBK裡面是0xB3C2,在UTF-8
【轉】MySQL索引背後的資料結構及演算法原理
摘要 本文以MySQL資料庫為研究物件,討論與資料庫索引相關的一些話題。特別需要說明的是,MySQL支援諸多儲存引擎,而各種儲存引擎對索引的支援也各不相同,因此MySQL資料庫支援多種索引型別,如BTree索引,雜湊索引,全文索引等等。為了避免混亂,本文將只關注於BTree