写在前面
活着的软件，不会停止更新。只是每一个软件更新（对外开放新版本）的频率不同。曾经TBtools平均每天一更，当然现在已经很长时间不更新了，或者确切地说，并不那么频繁地推出新版本了。这或许有两个方面的原因：
- 经过大部分用户的测试和使用，软件的大多数常用功能鲁棒性较好，不会有程序上的问题，所以无需更新；
- 常见的需求会被提出，但需求类型是有限的。TBtools从某个角度来说，其实只是做了以前一切公司不愿意去做的事情，比如解决一些序列提取，自定义集合富集分析，Blast和系列可视化等（当然，现在很多公司的云平台也可以做，但是你也会发现，来来去去也就是那些功能）。
但回过来说，软件的新版本推出又是必须的，这或许是另外三方面的原因：
- 已有的功能存在不足，必须尽快更新，或者说是bugs fixing。这也是我一直希望所有人跟上TBtools的最新版本，虽然很少人接收到我的信息。这可能是因为，TBtools本身用户使用逻辑就是，打开，使用，关闭，换句话说，有种日抛型隐形眼镜感觉。
- 常见的需求是有限的，但新的需求是可以开发的，比如前面TBtools推出的掰弯的热图，似乎还是有不少用户需求。但是至少，从目前来看，并不存在哪个公司或者云平台去做这个事情。或许有一天大家也都能做呢？（事实上，似乎没有人注意到，TBtools掰弯的热图可以从命令行直接出图，这意味着存在一些公司，完全可以通过调用，直接输出掰弯的热图）。
- 已有的特性增强，较大地提高软件功能和用户体验。正如今天推送的主要内容，我们课题组基于植物small RNA测序数据深度挖掘需求而设计的IGV-sRNA。
前述，可见标题，我们已经对IGV进行了六次改造，得到了IGV-sRNA v0.1.6，课题组做小RNA数据深度挖掘的需求已经满足，但在使用过程中，我们仍然发现一些问题（用户基数太小，暂时仅限于XiaLab和合作课题组，所以问题发现的速度也慢，这与TBtools形成鲜明对比）。既然发现了问题，那么我们就又对IGV-sRNA进行了第七次较大的改造，从而得到IGV-sRNA v0.2.x。
改造结果
更低的内存需求，更多的数据加载能力
IGV在进行读段数据可视化时，为了节省内存，其会对Read进行DownSample。这个本身没问题，但这就意味着，在Track中可使用的数据，是已经采样的数据，无法用于正确地进行其他Track如ReadLen或Phas Score的计算。在IGV-sRNA v0.1.x中（尤其是后期版本），我们采用的是重量级操作，直接在上游保存所有Reads到内存。这看起来似乎并没有问题，但事实上会直接造成内存占用的快速提升，同时卡顿的现象非常明显（jvm的GC效率并不高）。尤其体现在32位的操作系统中。在这里可能会有朋友认为，那我们可以直接在Track中调用AlignmentFileReader，重新读取。这里则会涉及两个问题，IGV本身涉及逻辑考虑了交互体验，同一个窗口不同的Tracks有延时装载，在LoadData上对读取逻辑进行了优化，这就使得我们增加更多地读取步骤，要么就强行读取，导致异常；要么就同步进去，直接增加了使用时间，失去意义。当然，这里还有一个I/O速度的问题。总的来说，我们使用了另外的逻辑，完成了这个问题的处理。所以现在基本上并不需要有多少内存的使用，即使你有再多的数据输入（比如我们将100个拟南芥sRNA sequencing data合并成bam作为输入）。
更好的collasped数据解析逻辑
在IGV-sRNA v0.1.x中，我们只在IGV中对collasped的数据进行实时解析，这是一个逻辑，但整体上其实增加了IGV读取Read Alignment数据的耗时。在IGV-sRNA v0.2.x中，我们直接修改htsjdk（这主要是IGV使用了它，我们课题组有自己的sambam解析类），从读取的层次直接解析，同时并不会增加内存的占用。这对small RNA测序来说是一个不错的选择。collpased数据的mapping作为IGV数据，我们可以减少硬件IO的次数，而增加内存中解析的次数，这是有赚无赔的操作。当然更不谈没有collasped和collasped之后的数据在readmapping和数据传输时的时间差。我们自然不能不知道，read mapping在很多时候mapping是一个问题，IO更是一个问题。
更合理的Read Len Dots Track展示方式
在前述，我们在IGV中增加了Read Length Track，这个track可以很好的辨识每个位点，匹配的不同长度的Reads的丰度，无论是在miRNA或者是phasiRNAs来源位点的观测上，效果均较好。但是在之前的版本中，我们并没有区分正反链，这样看起来并不清晰，尤其是对于PHAS loci。在新的版本中，我们将比对到正反链的Read Dots分开展示，同时在中间加一条线。可以很好的区分正反链。
更好的丰度指示方式
在IGV-sRNA中做数据探索时，我们常常会遇到这么一种情况，下图（拟南芥TAS3），
可以看到，这整个位点有一个极高丰度的读段，使得其他点无法被清晰的查看。我们很清楚，这是一个PHAS位点。所以此时，我们打开IGV-sRNA的Real time Phas Score calculation track，或者是直接对ReadLen Track，进行Set DataRange，如设置1000，得到以下
这样的效果就比较明显，有小RNA数据分析经验的可以大体判断出其很可能是phas位点。上图出来，其实很明显，我们可能无法判断该位点的丰度到底是超过1000，还是接近于1000，所以，我们又增加了特性，使用三角形展示丰度更高的数值。
事实上，我们从这些三角型的分布方式，就可以更确定，是Phas位点无误。
更智能的auto-scale
上述，我们使用1000作为最大值，但他对当前位点有用（示例数据是1000套sRNA sequencing data，所以丰度都很高），并不是每个位点都比较有效。比如另外低丰度的位点，我们可能需要设置150。基于这个需求，我们在IGV-sRNA v0.2.x中增加了选项，Top50 as MaxRange。也就是把丰度排名前第50的丰度作为当前区间的最高丰度。这样我们就可以在很多时候，减少用户的Set DataRange操作，如下
更快的Phas Score 实时计算逻辑
无论上述我怎么说ReadLen Track的查看，在Phas位点的鉴定上有多大用处，但都不是解决的根本。更好的办法是查看Phas Score的分布。在官方的IGV中，用户一般需要对每套数据自行计算好Phas Score的BedGraph文件（一般是Mb级的文本），随后导入IGV，这不仅增加了处理复杂度，更增加了内存的使用。最好的方式是实时计算。在IGV-sRNA v0.1.x中，我们已经实现了Phas Score Calc. in Fly-time。用户只需像正常使用IGV一样拖动即可同步查看任意位点的Phas Score情况，但之前的计算逻辑相对重量，见上文。在IGV-sRNA v0.2.x中，我们启用新逻辑后，现在几乎实现零延迟，目前测试效果是毫无卡顿感。总的来说，这是一个非常重大的增强。
更清晰的Phas Score Tracks可视化方式
在前述版本，我使用的是Bar Plot去绘制Phas Score，但这点与博士导师（Dr.Xia）的观点有不一致。其提出，往往在发表论文中，我们使用的Line Plot。当然，这是一个事实。一开始我是抗拒的，但实现起来其实难度并不是很大。于是我增加了Options。
具体博导可以用他喜欢的Line Plot，我可以用我喜欢的Bar plot。当然，似乎我现在也接受，Line Plot似乎确实更好看。这主要是因为secondary PhasiRNAs的Peaks确实在lIne Plot中更容易辨识。
一个更优秀的IGV-sRNA，即v0.2.x
写在最后
马上就是暑期了，提前祝大家暑期快乐，科研顺利！
修改版IGV的获取方式
近日有多个朋友联系过来，想要使用这个改造后的IGV。嗯...
我个人的想法是：
- 付费，如资助XiaLab课题组出游一次，大体价格是3K，那么将获得本年度（如果还有更细的话）的我经手的IGV更新功能。
- 直接联系课题组PI即RX获取，课题组主页为 http://xialab.scau.edu.cn/
