CentOS重新啟動後無法上網&fread與imread讀圖片的差別

一、CentOS重新啟動後無法上網問題

真實機器（不是虛擬機器）本來好好的，有網線（網絡卡enp0s31f6）有wifi (enp1s0)可以上網的，之前重新啟動N次都依舊可以上網。但昨天一次重新啟動後居然無法上網，怎麼都連線不上。

網上的很多辦法都試過了，結果把本來仍有的enp1so都搞沒了：

enp1s0沒有了，於是ip link set dev enp1s0 up 想將這個網絡卡重新啟動，然後再用ip addr 好像就看到了enp1s0 （此處不太記得了）。

但是此時service network start仍舊是失敗的，

此時 cd /etc/init.d 或者/ect/rc.d/init.d 後 ./network restart 仍舊是失敗的（此處也不太記得了）。然後按照  https://www.cnblogs.com/yxyht/p/5063505.html 在/etc/sysconfig/network-scripts/下新建了一個ifcfg-enp1s0，按照ifcfg-enp0s31f6裡面的內容，修改相應地方。

但是重新啟動後 service network start 仍舊是失敗的，但是 ping www.baidu.com已經通了。證明可以上網了哈哈。

具體原因我也不太清楚。

二、fread()與imread()讀取bmp圖片的差別

之前是用opencv讀取bmp圖片Mat.data拿到圖片指標然後對映到buffer會導致嚴重的記憶體到記憶體的拷貝問題，嚴重拉低了OpenCL

的效率。所以只能改用fread()直接讀到buffer的對映指標內，這樣就避免了CPU到CPU的拷貝。我用的是：

bool readBmp2Ptrwhole(char *BmpFileName,uchar *imgdata)
 
{
 
FILE * pFile;
 
int dataOffset;
 
pFile = fopen(BmpFileName,"rb");
 
if(!pFile)
 
{
 
return false;
 
}
 
//得到資料的偏移位元組
 
fseek(pFile,DataOffset,SEEK_SET);
 
fread(&dataOffset,4,1,pFile);
 
//得到bmp的寬與高的畫素數
 
fseek(pFile,SizeOffset,SEEK_SET);
 
int bmpWidth,bmpHeight;
 
fread(&bmpWidth,4,1,pFile);
 
fread(&bmpHeight,4,1,pFile);
 
//注意,有些圖片存在取出為負的情況
 
bmpWidth = abs(bmpWidth);
 
bmpHeight = abs(bmpHeight);
 
fseek(pFile,BiBitCount,SEEK_CUR);
 
int bmpBiBitCount;
 
fread(&bmpBiBitCount, 2, 1, pFile);
 
//printf("biBitCount %dn",newBmpData->bmpBiBitCount);
 
//點陣圖片資料分配空間
 
int BytesPerPixel = bmpBiBitCount / 8;
 
int LineLength, TotalLength;
 
LineLength = bmpWidth * BytesPerPixel; // 每行資料長度大致為圖象寬度乘以
 
// 每畫素的位元組數
 
while( LineLength % 4 != 0 ) // 修正LineLength使其為4的倍數
 
++LineLength;
 
TotalLength = LineLength * bmpHeight; // 資料總長 = 每行長度 * 圖象高度
 
// imgdata = (unsigned char *)malloc(TotalLength * sizeof(unsigned char));
 
fseek(pFile,dataOffset,SEEK_SET);
 
fread(imgdata , sizeof(unsigned char), (size_t)(long)TotalLength, pFile);
 
fclose(pFile);
 
return true;
 
}

用這個讀到已經分配好的imgdata內。但我發現與opencv的imread得到的Mat.data資料不一樣。我以為是上面這個函數錯的，讀圖有問題，於是我用下面這個函數將剛剛讀到的imgdata轉化為圖片儲存，看是否與原圖一致：

bool SaveBmp(int w, int h, unsigned char *pdata, char *BmpFileName, bool IsRGBA )
 
{
 
#define BMP_Header_Length 54
 
unsigned char header[BMP_Header_Length] = {
 
0x42, 0x4d, 0, 0, 0, 0, 0, 0, 0, 0,
 
54, 0, 0, 0, 40, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, IsRGBA ? 32 : 24, 0,
 
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 
0, 0, 0, 0
 
};
 
long file_size = (long)w * (long)h * (IsRGBA ? 4 : 3) + 54;
 
header[2] = (unsigned char)(file_size &0x000000ff);
 
header[3] = (file_size >> 8) & 0x000000ff;
 
header[4] = (file_size >> 16) & 0x000000ff;
 
header[5] = (file_size >> 24) & 0x000000ff;
 
long width = w;
 
header[18] = width & 0x000000ff;
 
header[19] = (width >> 8) &0x000000ff;
 
header[20] = (width >> 16) &0x000000ff;
 
header[21] = (width >> 24) &0x000000ff;
 
long height = h;
 
header[22] = height &0x000000ff;
 
header[23] = (height >> 8) &0x000000ff;
 
header[24] = (height >> 16) &0x000000ff;
 
header[25] = (height >> 24) &0x000000ff;
 
FILE *pWritingFile = NULL;
 
pWritingFile = fopen(BmpFileName, "wb");
 
if( pWritingFile == NULL )
 
return false;
 
fwrite(header, sizeof(unsigned char), 54, pWritingFile);
 
int BytesPerPixel = IsRGBA ? 4 : 3;
 
int LineLength, TotalLength;
 
LineLength = w * BytesPerPixel; // 每行資料長度大致為圖象寬度乘以
 
// 每畫素的位元組數
 
while( LineLength % 4 != 0 ) // 修正LineLength使其為4的倍數
 
++LineLength;
 
TotalLength = LineLength * h; // 資料總長 = 每行長度 * 圖象高度
 
//fwrite(pdata, PixelDataLength, 1, pWritingFile);
 
fwrite(pdata, sizeof(unsigned char), (size_t)(long)TotalLength, pWritingFile);
 
// 釋放記憶體和關閉檔案
 
fclose(pWritingFile);
 
return true;
 
}

結果儲存出來又是與原圖一致的。說明這兩個函數都是正確的。

結果同事告訴我，是bmp的編碼格式問題：https://blog.csdn.net/herbenlam/article/details/53432004   這裡說明了bmp是按從下到上編碼的（這也表現在 fread(&bmpWidth,4,1,pFile); fread(&bmpHeight,4,1,pFile); 這兩句得到的高寬是負數，負數表示從下到上，正數表示從上到下），而opencv是將bmp的從下到上轉化了一下轉化為從上到下在Mat.data裡。而fread（bmp）和fwrite（bmp）都是從最後一行讀（寫）到第一行從而完成對bmp影象的讀（寫）。

所以我比較了readBmp2Ptrwhole（）讀出來的最後一行與opencv的imread的Mat.data的第一行，果然資料一致了。

哎，想問題不夠深入。

Linux公社的RSS地址：https://www.linuxidc.com/rssFeed.aspx

本文永久更新連結地址：https://www.linuxidc.com/Linux/2018-08/153585.htm