思考以下两个问题：
1、一幅遥感影像至少好几个G甚至好几十G大小。比如高分二号影像星下点地面像元分辨率全色0.81米，幅宽45.3km，那么总像素可以粗略计算为55925*55925=3127605625个像素（30亿个像素），一幅全色影像像素约为30亿个，这还没有计算多光谱影像像素总数，这样一幅影像对于普通的数码相片，简直是小溪看到了大海，如果以普通的数字图像处理技术处理几乎不可能。
2、对于大片区作业来说，影像覆盖范围横跨几个市，几个省，影像数据体量非常可观，几百G，几百T也是很稀疏平常的事情，一幅影像就足以让人生畏了，何况几千幅、几百万幅这样的影像放在你手上。
有人估计会说，我购买遥感影像处理软件，几千万幅影像都不是问题，比如像素工厂、DPGRID等。不过遗憾的是，编写像素工厂、DPGRID软件的人似乎就不能像你这样高枕无忧了，他们需要绞尽脑汁地想出很好的一个策略来处理此类大规模的影像处理问题，想办法把CPU、内存、GPU的利用率提高了，实在不行，弄上几百台高性能服务器组成集群来干这个事情都行。
思想：分而治之
1、分块
对于单幅大体量的影像而言，将一幅影像直接导入内存，内存会被撑爆的，通常的思路是把一幅影像分块来处理，不少影像读取函数也支持分块读取，按行、按列、按整块的行列block一块一块的将影像导入内存，这样既不会占满内存，也会给进程足够的内存空间，对每一块进行处理。
2、CPU并行
分块是一个好的选择，不过总是串行处理数据的，现行的CPU都是多核结构的，那么开启多线程，多进程，充分利用每一个CPU核心并行对分块数据或者分幅影像处理，可以加快影像处理的速度，此时需要把处理影像的算法嵌入到每一个线程或进程里面。
3、GPU并行
GPU加速原理跟CPU并行处理影像原理相似，CPU与GPU在并行处理数据方面都有了长足的进步，细数它们之间的差别，一个缓存大，一个核心数多，一个线程执行时间长，一个任务分块数大，将分块数据或者分幅影像放到GPU里面处理进行加速其实也不错。
4、服务器并行
即便是有了CPU、GPU并行，遥感影像的数据量还是显得那么的庞大，那就上集群服务器吧，对他体量的遥感影像数据进行任务分发，使得每一个高性能服务器都能够独立的在网路环境下进行大规模的影像数据处理，加快大片区的影像处理速度。
以上几种方法以不同层面实现高性能处理遥感影像数据的方法，而这其中的任务调度算法是至关重要的，因为在影像自动化处理过程中，难免会有冲突，竞争计算资源，竞争内存，竞争网络宽带，搞不好集体罢工给你看，有的甚至想到了CPU+GPU+服务器混合并行。。。。。。。
MPI计算服务器集群并行计算
OpenMP多核心CPU并行计算
CUDA 多核心GPU并行计算
优化无止境。。。。。
