The first weekly report of the second week on October 29, 2018

我的代码将于2018/11/2更新到GitHub，届时会提供地址。https://github.com/Limingxing00/ImageProcess

 0.数据介绍      

        博主有一个如下的数据，现在任务是将img（这个数据的代称，后续将简写为img）抽出成一系列 size =（2048， 788）的图片序列。我们可以把他看作[3，851，2048，788]的4-D数据，物理意义是：把一个东西分成3块，每一块切成851片，每一片可以看作是一个图像，大小为2048X788。

Dimension [C, Z, T] = [1, 3, 851]
[Width, Height] = [2048, 788]

1.导入数据

        利用计时模块，导入2.7g大小数据花销情况如下。（IDE：spyder，内存：8g）

2.数据分析

        导入后的img是一个numpy的array，dtype = uint16。这块有个小细节：我想要导入的img理想维度信息应该是[3，851，2048，788]，可是python导入后数据轴的顺序乱了，博主做了一些实验，我们可以通过调用 img[90,:,:,1] 这样的方法，而不用reshape等函数改变维度（反而增大计算开销）。

        但是考虑到计算机硬件影响，博主对数据集进行了“裁剪”，见下一章。

3.自制：小样本

        由于导入后的数据是numpy格式的，自然而然想到npy保存多维数组，这里我也进行了实现，得到了一个比较有意思的发现。下面是我保存数据的语句，我只是把851那个维度的保存了200组，这样子我们在后续安排好API对接上就行了。

np.save(r'D:\Liu_Dong\Brain_map_compression\ZhangYueYi\raw_brain\img\00.npy',img[200:400,:,:,:])

 保存得到的npy如下

        是不是有点问题？我只保存了大概25%的数据，但是却占了原来Raw.ome.tif 的66%的空间，这里博主猜想原始数据可能经过了某种压缩，而npy可能没有经过压缩或者压的少，给我们带来的好处可以见下一章。

4.小样本的运行情况

        数据由2.7g->1.8g，但是导入时间变成了17s，几乎提高了10倍导入速度......我猜想这个原因可能是原始数据导入要解码，增大了时间的花销。

        不管怎么样，我们自制的小样本已经准备好了，接下来就是抽离图像的模块。

5.抽离图像

        最直白的第一个想法就是for循环，按照线性索引，把他导出完事。事实上好像也只能这么做，因为读出的函数是封装好的cv2.imwrite，这个函数只能进一个二维数组出一个图保存，所以以后优化最直接的方法就是换一个gpu的类似功能的函数，进好几个图，出好几个图（*记录）。这里，先进行最初的版本。

5.1最初版本运行情况

        对，你没看错。。导出数据多了1s左右，所以按照木桶效应，我应该主动优化数据导入。（*记录）

337.8163847923279
199.86016464233398

35.25764008870118