超大图片的储存/处理/显示

大图是指那种G级别，目前测试使用的图片大概是几万乘几万像素的灰度图。也就是其大小内存仍是能够读入，可是须要对数据结构进行设计来达到优化使用的目的。
对于那些图片自己信息已经大于内存的数据，只有一些简单的思路，没有实现。
文章里只包含一些问题的总结和思路，没有具体代码和方案。

内存中储存

c++程序里对内存没有限制，只要别大于机器的内存就行。可是C#中有一些奇怪的设定，首先是32位平台下单个程序默认不容许超过2G。这个解决起来比较简单，直接在vs工程中修改某些设置就行（具体的话直接百度吧）。 另外还有一个限制，是我本身总结的，由于没有看到专门说这个的内容，就是单个内存地址，也就是申请的内存，也不能超过2G（具体大小没有测试，大约这个范围）。之因此得出这个结论，是由于在测试申请一个大于2G数组的时候，他会overflow，可是若是你申请的是4个512M的数组，就会一切正常。Mat/Image这两个类也是同样。应该就是他没法取出这么大的 连续空间的内存吧。

因此针对这个限制，个人解决方案是设计一个类，来实现大图片的分块读取和存储。为了提升效率，能够直接用byte的二维数据来作块，须要设置每块数据的最大上限，保证不超过（单个连续空间的最大值），同时这个最大上限会对图像的访问效率产生影响，因此须要必定的测试和修改。
这样就能够保证经过多个小内存，来储存一个大数据量图片的目的。

图像浏览

图像浏览这个需求可能就稍微小一点了吧。最典型的大图浏览其实就是地图，谷歌地图，百度地图应该都是用的相似算法--图像金字塔。

其实这个词一说出来这个算法应该就差很少知道了吧。就是在内存里生成一系列不一样分辨率大小的图片，根据浏览需求的视场大小，选择合适的分辨率图片，从而输出一个（用户看的比较清楚，同时又尽量小的图片）。是一种牺牲空间（内存）来换取时间的方式。

超超大图片

这个只是我又本身作的拓展出来的一些思考。

若是图片真的超级大，连内存里也存不下了，就只能用硬盘了。固然这里的硬盘最好是固态的了。其实内存和硬盘本质差很少，不过就是内存的读取速度快一点而已，因此若是图片大小真的超过内存了，那使用硬盘也是没有办法了。

能够在基于分块储存和金字塔的基础上，把一些访问率比较低，或者完整的大分辨率图像，经过某种储存和索引方式，存到硬盘里。（感受说了和没说同样，难点应该就在于如何设计这种索引方式来达到高效读写吧）