数据图像GDAL对于raw数据支持的一个bug

首先声明，我是一个菜鸟。一下文章中出现技术误导情况盖不负责

    下面的GDAL版本针对最新的1.10.0而言，对于GDAL1.9.2问题照旧。

    最近在处理卫星的长条带数据，图像的行数差不多200w行阁下，格式的raw格式。可以应用VRT文件来很方便的对raw数据进行管理。比如要提取raw数据中的某一部份等等。由于处理的数据是1536列的16bit数据，并对raw数据进行提取。比如指定从多少行开始，到多少行结束。关于VRT数据进行管理raw数据可以参考《应用GDAL打开裸数据（RAW）》http://blog.csdn.net/liminlu0314/article/details/7753377和《应用GDAL下载并转换SRTM的DEM数据（二）》http://blog.csdn.net/liminlu0314/article/details/8272394这两篇文章。

    原来功能已实现，明天测试说起始位置超越70w行（最后定位到如果大于即是699051行就会出错）提取出来的数据就不准确了，开始觉得多是我的程序写的有问题，因为我的程序图像的宽高偏移量都是用int，最大值应当是2147483647，对于图像的宽高来说，这个数完全够用，可是对于图像的偏移量就不必定了。

    图像的偏移量就是指图像的第一个像元值先对于raw文件的起始位置的字节数，比如下面的问题，就是出在这个图像偏移量，由于之前用的是int来进行存储，对于最大值来说就是2147483647。

    由于每行图像是1536列的16bit数据，所以每行就是3072字节，699051行就是2147484672，这个值已显著大于int所能表现的最大值2147483647了，看来问题就是出在这里了，按照这个思路将程序中的图像偏移量全体用__int64进行表现，按理说不会出现问题，可是问题照旧。

    初步查看了一下GDAL的源代码，发现图像的偏移量是用的一个名为vsi_l_offset的类型进行表现，查看定义会发现下面这样的重定义：

/* ==================================================================== */
/*      64bit stdio file access functions.  If we have a big size       */
/*      defined, then provide protypes for the large file API,          */
/*      otherwise redefine to use the regular api.                      */
/* ==================================================================== */
typedef GUIntBig vsi_l_offset;

     以及

/* -------------------------------------------------------------------- */
/*      64bit support                                                   */
/* -------------------------------------------------------------------- */

#if defined(WIN32) && defined(_MSC_VER)

#define VSI_LARGE_API_SUPPORTED
typedef __int64          GIntBig;
typedef unsigned __int64 GUIntBig;

#elif HAVE_LONG_LONG

typedef long long        GIntBig;
typedef unsigned long long GUIntBig;

#else

typedef long             GIntBig;
typedef unsigned long    GUIntBig;

#endif

     从下面的定义来看，vsi_l_offset实质上就是一个64为的无符号整型，按理说不会出错啊，可是为什么还是会出错呢？继续调试GDAL的代码，在文件f:\Work\3rdPart\gdal-1.10.0\frmts\vrt\vrtdataset.cpp的926行阁下，会发现下面的代码：

    每日一道理
聪明人学习，像搏击长空的雄鹰，仰视一望无际的大地；愚笨的人学习，漫无目的，犹如乱飞乱撞的无头飞蛾；刻苦的人学习，像弯弯的河流，虽有曲折，但终会流入大海；懒惰的人学习，像水中的木头，阻力越大倒退得越快。

/* -------------------------------------------------------------------- */
/*      Collect required information.                                   */
/* -------------------------------------------------------------------- */
        if( CSLFetchNameValue(papszOptions, "ImageOffset") != NULL )
            nImageOffset = atoi(CSLFetchNameValue(papszOptions, "ImageOffset"));

     最后发现是函数atoi出问题了，查看MSDN的说明，会发现atoi函数，对于超出int存储范围时会返回int存储的最大值或者最小值。按照下面的偏移量是2147484672，通过下面这句代码转换的结果就成2147483647，从而致使后续定位错误，致使提取的图像失败。晓得原因，我们就可以应用一个函数来替换atoi这个函数。下面是我写的一个函数用来替换atoi来支撑int64，具体如下：

// define atoi64 transform string to 64bit int
GIntBig atoi64(const char * str);
GUIntBig atoi64u(const char * str);

// function implementations
/* -------------------------------------------------------------------- */
/*      string to 64bit int support(liml 2013-5-17)                     */
/* -------------------------------------------------------------------- */
#if defined(WIN32) && defined(_MSC_VER)

GIntBig atoi64(const char * str) { return _atoi64(str); }
GUIntBig atoi64u(const char * str) { return _strtoui64(str, NULL, 10); }

#elif HAVE_LONG_LONG

GIntBig atoi64(const char * str) { return strtoll(str, NULL, 10); }
GUIntBig atoi64u(const char * str) { return strtoull(str, NULL, 10); }

#else

GIntBig atoi64(const char * str) { return _atoi64(str); }
GUIntBig atoi64u(const char * str) { return _strtoui64(str, NULL, 10); }

#endif

     下面的代码在Windows平台下测试通过，Linux下没有进行测试，准确性未知。有了下面的函数，就可以用函数atoi64来代替下面的atoi函数即可，然后重新编译生成GDAL，替换原来的dll即可。

    修改下面的代码后，这个提取的问题解决，可是应用GDAL打开之后关闭发现又出问题了，显示的图像不准确。继续调试代码，还发现两处代码，分别是：文件f:\Work\3rdPart\gdal-1.10.0\frmts\vrt\vrtrawrasterband.cpp的334行和403行阁下：

nImageOffset = atoi(CPLGetXMLValue( psTree, "ImageOffset", "0") );

/* -------------------------------------------------------------------- */
/*      Set other layout information.                                   */
/* -------------------------------------------------------------------- */
    CPLCreateXMLElementAndValue( 
        psTree, "ImageOffset", 
        CPLSPrintf("%d",(int) poRawRaster->GetImgOffset()) );

     对于下面第一处，将atoi函数替换为atoi64即可，对于第二处将%d替换为%llu并将前面的强制类型转换(int)去掉即可。

    通过下面的修改，对于raw格式的大图像偏移量应当不会出现什么别的问题了。一个无符号的int64最大值应当是18446744073709551615，换成字节的话，差不多是2048的PB，这下应当足够大了。应当不会有一个文件大小能够变态到这类田地。

    PS：已将这个bug提交到GDAL开辟组，不出所料的话应当下个版本会修复，GDAL开辟组修复问题还是非常及时的。

文章结束给大家分享下程序员的一些笑话语录： 爱情观
　　爱情就是死循环，一旦执行就陷进去了。
　　爱上一个人，就是内存泄露--你永远释放不了。
　　真正爱上一个人的时候，那就是常量限定，永远不会改变。
　　女朋友就是私有变量，只有我这个类才能调用。
　　情人就是指针用的时候一定要注意，要不然就带来巨大的灾难。