彩超框架EchoSight开发日志记录

Z_Jiang

已于 2024-04-06 11:23:59 修改

阅读量1.8k

点赞数 38

分类专栏：医疗超声文章标签：彩超超声系统工程框架超声信号链路 EchoSight

于 2024-01-16 00:03:51 首次发布

本文链接：https://blog.csdn.net/gamer_gerald/article/details/135611461

版权

医疗超声专栏收录该内容

8 篇文章 49 订阅

订阅专栏

EchoSight开发记录

作者：蒋志强

不定期更新EchoSight开发日志记录，最近更新于2024年04月06日

1.背景

由于某些不可抗逆的原因，离开了以前的彩超大厂，竞业在家，难得有空闲的时间。我计划利用这段时间 自己独立从零开始 搭建一套彩超系统的软件工程框架。这个框架的设计水准力求达到目前商业级产品中第一梯队的水平。

这套工程框架，我暂时取名为EchoSight。Echo表示声音/回声，Sight本意为视野/看见的意思，所以EchoSight就是通过超声成像的意思，非常务实；开发基本完成后，如果没有什么特别原因，我会把程序分享出来（可执行程序），请各位业内大牛指教。

作为目标达到商业级优秀的工程框架，EchoSight需要满足很多的要求，包括：

1. 框架的可扩展性；

2. 框架的高度灵活配置性；

3. 后续扩展开发的模块独立性与低耦合，以及模块的封装；

4. CPU线程调度的安全高效与透明简单；

5. CPU SIMD与GPU执行的高效实时性；

6. 离线仿真配置与在线运行配置的近似性与可替换性；

7. 彩超链路分析与输出的便捷接口；

8. 工程框架与matlab良好的联调机制；

其它更多 TBD...

因此，这会是一个满大的挑战，特别是对我自己一个人独立开发而言。自己最终在这段时间内能做什么程度，我自己也不知道。这样挑战的单人项目，已经处于我个人能力圈的边缘地带，能做成什么样，实践是检验能力的唯一标准。干，就得了，生死看淡，不服就干！

随着项目的推进，也许自身在系统上的短板或工程的短板就暴露出来了，补上了，自己能力圈也就扩大了。

2.开发进展记录

2.0 初步构思

（难以记时）

基本框架思路成型，然后又推倒几次，目前觉得基本可行。

2.1开发环境搭建服务器搭建完成

（2023年12月15日）

工程代码，开发设计文档，系统仿真内容 SVN服务器搭建完成。

Q：为啥不用GIT ?

A：GIT用得不熟，SVN用得多。开发的辅助工具，不在这些无关紧要的东西上本末倒置。

开发环境选择为VS2022，纯C++不使用依赖任何基础框架。

其实QT提供了很多库，.NET也提供很多不错的框架。但我是做底层框架开发，纯C++的开发完成后，可以做到几乎零依赖零绑定，与几乎任何框架集成匹配，在几乎任何操作系统上运行。而VS在底层复杂问题上的调试工具比QT Creator丰富强大，QT更擅长于UI开发，包括QT对OpenGL的封装，对我来说也没有必要，原生底层调用才是我需要的。

系统仿真工具为Matlab2022,没啥说的，也没有备选工具。

仿真平台Field II, KWave, Focus与MUST。这几个仿真工具各有特点，看各个阶段的需求交替使用。

2.2 基础类的设计与多线程策略

（2023年12月25日）

基础类框架的设计开发第2次推倒重构，C++从ISO C++11改为C++20，以便使用C++最新特性设计。各模块空转情况下，多线程运行正常；

2.3 离线数据模块工作正常与多模块配置正常

（2023年12月30日）

通道数据仿真模块连线，注入数据正常，与其它各模块多线程配合未见异常。

扫查序列定义解析正常，链路多模块配置与运行时自动搭建正常，XML解析正常；

2.4 Matlab仿真数据与工程匹配

（2024年01月09日）

仿真数据不能完美符合自己的需求，重新实验多种仿真工具field II, KWave, Focus,PField,MUST等。顺便还发现了某仿真平台里的又一个BUG，与作者联系沟通。

更新开发设计文档。更新标准IQ波束合成模块，B模式模块。软件连线工作正常，图像结果异常，调试进行中...

2.5 数据解包模块重构与波束合成更新

（2024年01月15日）

解包模块重构，支持任意FPGA打包策略。matlab仿真找到折中方案，满足需求，更新离线数据。

标准IQ波束合成模块调试，解决若干BUG（调试脱了一层皮），更新MLA支持，更新变迹计算的更优策略。

标准IQ波束合成工程输出与 matlab输出基本匹配，未见明显异常。节前重要阶段性节点！

2.6 B模式处理更新与RTB IQ波束合成模块

（2024年01月19日）

系统仿真导入数据更新，B模式链路更新基本处理，分离单独线程。

RTB IQ波束合成基础软件模块完成，程序调试跑通，目前结果未见异常。

但毕竟是仿真数据，我也不能完全确信是否正确，例如靶点太粗。如果有同仁手上有真实硬件通道数据方便分享，请后台留言，不胜感激。仿真的scatter太少，有些结果不能完全确认，

即使比较少的scatter产生一次通道数据都要跑10个小时，如果要达到我期望的精度，matlab仿一次通道数据，一周过去了。

正在重构基础类，内存管理思考中，目前内存爆表，各个子线程内部的子线程池策略思考重构中，合成孔径开发进行中。

目前调试结果，均需要dump文件，甚是不便，后面我看能不能把OpenGL加进来，作个简单的显示和扫描转换，用作后面调试使用。哎，事情太多，都得自己搞，感觉忙不过来。

2.7 RTB 与相位计算问题BUG解决

（2024年01月21日）

波束合成继续Debug，发现并修正计算与量化重大问题，靶点大小终于正常了。

完成波束相位修正计算，加入软件链路中，结果未见异常。

根据自己的经验，目前已基本能确认计算正确，即使没有真实的通道数据，也能确信结果，置信程度颇高（即便达不到6西格玛也有4西格玛以上）。

提高了通道数据底噪，便于下一步与合成孔径后的软件链路结果对比；

下一步工作，计划先完成合成孔径，然后开始一次大的框架重构，软件重构的思路构思中。

2.8 合成孔径初始调试正确与其它

（2024年01月25日）

合成孔径调试通过（调试费了不少劲），连接其它软件模块后，目前工作正常，图像输出未见异常。与上次的输出进行对比，近/中/远场信噪比穿透对比分辨率提升，完全符合预期。

上面右图是在MLA为64，开启RTB回溯，搭配多次合成孔径，使用相同的MOCK通道数据输入，与上一次的图像相比提升明显。调试虽然辛苦，总算是调通了，内存暂时没有爆掉。

我之所以先做聚焦波，后面再加平面波的支持，不光是因为聚焦波的情况比平面波难做，包括是焦区处的处理与调试等，还因为就图像品质而言，由于Grating Lobe的干扰，聚焦波综合图像质量优于平面波。当然，平面波的大声场覆盖有利于HFPS，大孔径有利于更细的靶点。作为一名系统工程师的工程框架设计，不会是选择题，我需要全都支持，以便给IQ调图工程师更大的选择范围。

下一步，我计划加个模块作为显示（说了好久了没做，哎，没办法，一个人干活得一步一步来），因为现在每次检查结果都是Dump写到文件，很是麻烦。而且几何关系也不对，做凸阵和相控阵时肯定是不行的，我也计划顺带在GPU端把扫描转换做了。这些前期准备工作完成后，暂停一下，其间好好构思一下重构的事，春节后将会做一次比较大的软件重构。

2.9 显示模块添加与扫描转换

（2024年01月29日）

这次总算把显示模块加上了，以后检查结果，就不用dump到文件了。为了确保几何关系正确，在GPU端把扫描转换也做了。

常规的软件一般把显示放主线程，计算在子线程。但对我来说，EchoSight是核心C位，显示是次要的Debug工具，所以显示被我排挤到子线程里，中间导致各种奇葩工程问题若干。幸好我坚持没有妥协，这些工程问题我都搞定了，目前显示模块搭配工作正常，扫描转换GPU计算看上去几何关系也应该没问题。

下一步，我想把线阵偏转的情况先做还是把相控阵探头先做。两者类似，但我都要mock up一下数据，满花时间的。另外，我有一种工程师直觉，预感我波束合成计算的代码里存在一个不可接受的量化误差。

I believe in Murphy's Law，需要想一想问题可能在哪里。

2.10 线阵的偏转

（2024年02月02日）

线阵探头的斜扫完成了，斜扫下的波束合成，以及相关处理。不出意外，又遇到一堆BUG，好消息是，都解决了。斜扫是常规操作，在空间复合，穿刺增强都要用，波束合成部分肯定要支持。处理结果没什么好说的，如下图

截屏视频做了个GIF动图，展示实际EchoSight软件框架运行时多角度扫查的运行状态

上次怀疑的波束合成问题，我已经找到并确认了，果然Murphy's Law从来没让工程师失望过。

那是一个非常重要，但往往被忽略的点，后期我想想怎么做。应该不能说是BUG，而是设计思路。每个厂家的系统工程师不同，系统方案也可能大相径庭，没有标准统一的做法，我就不多废话了。那个点在凸阵斜扫时，我预期会变得比较明显。后期，我比较期待，能看到相对明显一些的artifact，然后找到合适又便宜的工程方案处理它。

另外，我还有感觉目前的斜扫质量还是比预期的差一丢丢，我担心哪里还有问题。Murphy's Law still,我再思考思考。最近，春节前赶进度，开发得有点激进，先怼这个问题，还是继续往后做相控阵？待定吧。。。

2.11 相控阵处理

（2024年02月08日）

最近忙着研究其它内容，刻意让进度慢些，相控阵还没做完。相控阵重新捣鼓捣鼓仿真数据，导入后基本工作，因为还没做相控阵的扫描转换，软件工程框架的输出也不好判断正确与否。

过节期间，停下来研究一下工程上一些非常tricky的内容，这是后面开发的基础，系统上的问题不大，主要是工程架构顶层设计与底层细节的问题，磨刀不误砍柴工。相控阵肯定要节后才能完成了，预祝大家新年快乐！

2.12 相控阵处理继续

（2024年02月19日）

新年后开工，继续年前的问题，把相控阵的扫描转换弄了，修正了一些相控阵情况下特别明显的问题。但还是有些问题摸不着头脑，目前结果如下，图像还是有错，可以看到圆圈有扭曲，靶点有不水平，如果扫描转换没问题，那问题应该在波束合成计算上，还得细致调查一下。

CPU模块的开发的同时，GPU模块的开发，已经同步开始了，新的GPU模块工程架构设计，都很花时间，后续开发日志更新会慢一些，慢工出细活，同样型号的GPU硬件，不同的做法，效率可能成倍或数倍差别。我需要平衡好理论与工程之间的妥协。

从工程设计要求上，希望独立显卡的版本在极限情况下支持几千帧，集成显卡版本的版本争取在极限情况下支持几百帧。我工程里的simulator模块正好可以用作系统极限压力评估。

2.X 理论学术闲逛

声速估算

过年期间，闲下来研究一下论文也算是很开心的事，看看学术界有哪些进展。其中有一个印象尤其深刻。在通道数据上倒算全场二维声速，仿真/体模/组织，结果令人印象深刻，论文的结果如下图。

应用前景应该很广，比如说拿到全场声速后，在二维上对波束合成进行校正，应该能显著提升图像质量，当然这样做的运算复杂度比普通软波束又要高很多，得在系统算法和系统工程两方面同时发力才有可能实时。再比如说，有了基于通道数据直接计算的声速，定量的弹性就已经有，就不用shear wave来算弹性了，大大降低了硬件电源与前端硬件的压力，还避免了声功率约束，没有shear wave发射，FPS也能更高。当然还有很多其它可以想到的应用功能拓展。

体渲染光追

图形学上也看到一些有意思的东西，我们超声的3D属于体渲染，游戏的渲染是基于面渲染。两者是不同的路，游戏目前把光线追踪 ray tracing 搬进了商业游戏产品。但体渲染要把光追加进去，比面渲染要难，我看到有比较新的研究做得不错，而且基本达到准实时的效率，它们结果如下图。

我觉得很不错，特别是在光追时还需要处理好蒙地卡罗采样噪声，也许不了解的朋友可能觉得做得一般。我要解释一下，体渲染还需要次表面散射的处理再配合上光线追踪才会理想。

现在体渲染+次表面散射大家能做实时，体渲染+光追能做到准实时了，就差体渲染 + 次表面散射+光追三位一体这将会是一个巨大的进步，工程上做到实时将会甩开市面上所有产品的效果，降维打击。

合成孔径补偿

我们现在做的就是合成孔径，多次合成绕不开运动的干扰。我看到有的研究在这一块儿的效果还不错，相关论文看下来我觉得是能做到的。它们的效果如下

在人体上实测结果，对于心脏这里快速运动的结果看上去也很不错

只要我们高效准确的处理好运动，那么波束合成更多的合成孔径次数的优势就会更加显著。从理论上来说，我有信心能用更高效的算法替代，但它思路是很好的，我以前就是专门研究这个的，细节就不展开了。

血流可视化

血流可视化是常见的高级功能，最常见是vector flow，但效果显然不符合人眼的爱好，看着头大，见下图左。通过粒子的流动表达更符合人眼直觉，这方面GE挪威团队几年前做的BSI感受更出色，见下图右。其实运动信息，我们都能得到，关键是设计好的符合人的直觉的表达；最近看着论文，看看气象云图，也许可以把这个结合起来，也许效果会更进一步，我得想想，满有意思的；

看论文推导一下公式时，时间总过得飞快。有时候想如果重回实验室，把工程放一放，做科研也是挺好的。不过，话说回来，理论与工程的结合，各占一半，把东西做进产品里，这才是系统工程师定位，不能太贪心，继续埋头搭EchoSight框架......

2.13 GPU波束模块初始连接成功

（2024年02月24日）

接着干活，最近忙着捣鼓GPU的模块，决定先搞定Nvidia上CUDA的版本，以后有时间再弄Intel/AMD的CL版本。新模块适配EchoSight架构，新的模块写好并加入进来调试通过了，导入数据也跑通了，中间遇到了太多问题，此处省略很多字。最后输出结果肯定还不对，但这都不重要，因为有些计算我还没做，关键是框架结构没有问题，通道数据在GPU上跑通了，架构没问题，链路跑通正确就是最大的成功。

下一步，接着先做GPU的模块还是继续前面phase探头的问题调查？看心情吧，有的时候卡壳时，换一换思路也是满不错的。

2.14 GPU波束模块开发调试

（2024年03月03日）

波束合成模块的遍迹计算设计进行了重大调整，某些创造性的工程骚操作，最后使得该部分计算量下降90%以上，数据传输量减少为不足原始设计的1%以下，同时精度反而比原始Naive方式更高。这是一个巨大的进步。

最终图像上修正了几个上次的问题，但依然还有明显问题，该问题不是遍迹带来的，但我还不确认问题在哪里，通道数据传输更新应该是正确的。

下一步，继续调试分析中，何时能正确，不知道，没有方向迷茫中... ...

2.15 GPU波束模块开发调试-续

（2024年03月06日）

GPU工程调试我都要崩溃了，晚上也睡不着觉，疙瘩角落的分析实验，总算找到了一个与我模拟仿真格式有关的一个BUG，图像往正确方向前进了一小步

但很明显，还有问题在里面，继续分析调试...... 要么拿下工程问题，要么被工程问题打垮

2.16 GPU波束模块开发调试-续2

（2024年03月07日）

只要不放弃，问题总归能找到，只是没想到这么快。这次修正问题后，图像看上去比较正常了，前进了一大步，虽然我还不能完全确认是否还有BUG。

最重要的是，之前奇葩（精妙）的遍迹方案设计，经确认工作正确，既是意料之中，也是意外之喜。我个人认为，这种思路的方案，如果是不做工程的系统研究员绝无可能想到，如果是没有系统研究背景的纯工程师也不可能想到。这是系统工程师的独有BUFF：多个角度的视角思路复合。现阶段的结果如下

这段时间的GPU调试开发，让我预感以前的CPU版本模块似乎有问题，回头有必要也去再检查一下。另外一个问题是目前的GPU版本速度太慢了，一帧处理在链路里居然花了300多毫秒！虽然现阶段主要的关注点是图像正确，框架设计合理，后期集中精力提升效率，提升上百倍应该是能做到的，但看着这么低的效率，心里感觉很不舒服，总有种冲动想先做少量的调整和提升。

下一步有几个备选任务

1.在GPU下完成RTB的多MLA；

2.检查CPU版本的波束合成问题；

3.进行一次中等规模的调整重构，初步提升一下效率（3~5倍即可）；

4.波束合成加入平面波的支持；

5.开始加入凸阵探头的支持；

6.继续调查之前相控阵波束合成的问题；

7. 血流部分的仿真工作开个头，为后期血流对接波束合成做一些准备；

8. 更新一下EchoSight的文档；

9. 其它临时想到的内容TBD；

备选工作项太多，就像自助餐，可以任君选择...... -_-||

2.17 GPU波束模块开发调试-续3

（2024年03月09日）

最近的时间间隔比较短，似乎进展很快，但实际是由于前段时间春节，总在思考分析，最近的推进快基本都源自前段时间的“暂停”。

更新了仿真数据，由于上次仿真数据格式有问题，导致之前调试走了很多冤枉路，这次把基础数据重新仿真替换以后就不会出问题。

在GPU版本的波束合成整合以后，这次是做了比较大的优化和重构，我本来不想搞这么大的调整，预期提升（3~5倍）效率即可。上一版的软件框架下，一帧的数据要300多毫秒，我又仔细看了看那还算比较好的情况，平均下来大概在360~390ms左右，GPU的计算Loading只有16~18%，PCI-E DMA数据传输使用率12~14%。

重构与优化后，相同的情况，当前版本可以做到平均每帧耗时下降到31~36ms左右，GPU计算Loading提升到了31~35%左右，PCI-E DMA数据传输使用率提升到了31~35%左右，数据处理吞吐率稳定在4 GByte/Sec，EchoSight框架综合性能表现是上一版本的11倍！！！运行情况见下图

图像结果与上次有点差别，主要是我重新做了仿真数据，这次的发射孔径要比之前开得大一些，所以信号强一点，旁瓣理论上应该比之前略大，但在图像上应该看不大出来。

每次仿真，我都有点害怕，因为我的机器是比较弱鸡的普通12代Intel i5 CPU。每次matlab都要在CPU负载100%的情况下连续运行十几个小时，我都害怕CPU太累了-_-||，中间如果有错matlab程序有BUG，还得重来。

这一次优化重构结果，是超出预期的进展，而且花的时间很短。这么少时间的投入，是一个假象，很多东西是得益于前期做架构时的思考预判和事先预留的设计，所以做调整时才比较容易，特别是遍迹计算的工程设计，实在是太奇特巧妙的做法了，使得在GPU计算和数据传输上帮助很多。现在GPU在工作阶段时，我估计运算并行度与数据吞吐率可能会被拉满，这在进行性能分析时，得到了验证，如下图

蓝色的块是计算，绿色的块是数据传输。GPU在每帧处理过程中，蓝色块几乎被填满（表示GPU计算几乎没有空闲），绿色部分也是几乎满的（表示PCI-E传输一直在忙），而且计算与传输的并行重合度也很高（表示传输和计算同时在忙，没有彼此等待与空闲），在这方面我很满意。

之所以在任务管理里GPU的计算与传输只有1/3左右的占用率，完全是由于每帧之间那段间隔空闲造成的，那段空闲占了大概2/3的时间。下一次再进行优化时，我应该就要对它动手了，压缩帧与帧之间的间隔，另外一条线是压缩GPU本身的占用时间，那是下下次优化时的事，目前正在整理思路中，这是架构层面的思考和分析，得好好想想，EchoSight内部有若干的独立模块，有若干的线程都在框架内部我自己进行维护，调度与配合。

目前，基本的GPU波束合成开发最基本的调试算是结束了，下一步就是GPU波束合成的常规功能性开发，例如以前CPU版本的steer处理，相控阵/凸阵的开发，配合合成孔径等预期风险会比较可控。

2.18 GPU波束模块开发调试-续4

（2024年03月13日）

这次更新还是处理线阵的情况，完成了GPU版本下的多MLA处理，RTB功能，偏转功能，同时与EchoSight框架的其它模块例如合成孔径配合，我原以为没有什么特别的(后来发现了异常)，目前在GPU版本下已经能工作运行，效率在上次重构优化后，目前可用。

但问题也很多，例如GPU寄存器等就不展开了，最核心的问题是图像相比CPU版本有不同。CPU版本我不敢完全说能够作为bench mark，但是GPU版本的输出看上去是有差别的，这种差别显然超出了量化误差的范畴，下面左边是CPU版本右边是GPU版本，相同的数据，相同的波束合成处理配置；

这类问题是我最担心的，因为排查十分艰难，非常耗时费力。接下来的工作，必须搞它...

2.19 GPU波束模块开发调试-续5

（2024年03月16日）

解决了CPU版本与GPU版本结果差异的问题，修复了波束合成的两个工程BUG，目前结果符合预期未见异常，CPU与GPU版本结果对比如下

CPU版本作为bench mark标准，本来作为对比，但CPU版本居然有一个潜藏很深的BUG，另外GPU的版本自身的确也有BUG，找到并修复这两个BUG后，两者对比如上图，我自己能够接受。

其实两者的计算还是有些差别，我个人认为GPU版本的结果反而会更好更准确一点。Anyway，如果交给IQ调图工程师，两个版本的结果他们应该都能接受。

另一个改进是偏转情况的处理，经过非常痛苦的调试和分析，GPU版本在偏转情况下，我大概提升了大概0.5dB~1dB的信噪比，在图像上看有一点提升，实际上这非常重要，在前端信号链上哪怕一点点的提升都是极其宝贵的，因为这部分太基础。常规偏转提升前后的对比如下图所示

常规偏转情况的动态对比，感受一下SNR差别

除了常规情况下的偏转，在合成孔径下的Steer下是另一个令人头疼的问题，因为理论上的原因，偏转的合成孔径的图像会有些异常。虽然不是BUG但这个问题我已经思考几个月了，希望能找到一个“便宜”的系统解决方案。

总算功夫不负有心人，经过不懈的努力，算是找到一种既“便宜”效果也还不错的工程方案。下图是合成孔径偏转下改进前后的对比效果

合成孔径偏转情况的动态对比，感受一下IQ差别

这个系统工程方案的优势在，1.工程上“便宜”；2.效果不错；3.前端处理，不牺牲分辨率不模糊；

任何前端的改进都是非常宝贵的，高端系统和普通系统的差异基本都在细节上，我对目前的结果比较满意。在常规信号处理阶段稍加处理，后期图像处理阶段应该不会被该问题困扰。我非常期待该方案在相控阵与凸阵偏转下的表现。

本次更新的内容蛮多，总结一下：

1. 修正两个波束合成基础性BUG，确保了CPU与GPU版本在线阵下基本一致；

2. 完成了一项偏转下SNR小提升改进，提升约0.5~1.0dB SNR；

3. 完成了一项偏转下合成孔径的固有问题改进，图像IQ进一步提升；

每一步进展都是硬骨头，进展超预期，虽然代码没敲几行，so far so good。下一步计划待定，又该重构一下工程框架了？进入相控阵的开发？或是进入凸阵的开发？and etc.

我觉得休息一下先，虽然不用上班了，但却反而累成狗。没有工作日休息日的区分，结果天天都是工作日，早上晚上半夜都在研究-_-||

休息，休息一会儿再说......

2.20 系统重构与相控阵

（2024年03月24日）

一提到20就联想到自主研发的巨大变动，什么歼20，直20，运20，轰20啥的，如果2.20的更新不大，出门都不好意思打招呼，-_-||

首先我进行了一次系统级框架的全面分析，确认了目前GPU版本配置下三个性能优化的发力点：

改进点A：占整体耗时60%，与底层架构，并与线程控制，模块配合等相关；

改进点B：占整体耗时20%，与中层架构，控制逻辑，CPU端并发性及其它相关；

改进点C：占整体耗时20%，与GPU计算，调度，访问效率相关；

通过分析改进点A，需要巨大的调整与重购范围，暂时不适合目前做，改进点C提升空间并不太大而且需要等到基本功能全部完成以后才合适开展，因此只能对改进点B展开工作；

然后，对改进点B展开重构优化后，对比（与2.17对比，相同数据相同配置情况下）结果如下

在2.17的状态下，平均每帧耗时大致在31~36ms左右波动，数据吞吐率为4GBytes/Sec，进行改进点B重构优化后，平均每帧耗时大致在28~33ms左右波动，数据吞吐率为4.5GBytes/Sec。

总结：整体EchoSight的全链路性能相比2.17版本，提升大概10%左右。

看上去"只有"10%，但实际上相当不容易，因为改进部分总共占耗时只有20%，所以该部分的性能提升需要在100%以上，才能在整个链路上反映出接近10%的提升。而且上一版本的性能基础并不算差，这次比较大的重构算是更进一步吧。

目前的性能，改改参数，例如在相控阵探头上降一下采样率（相控阵频率低），降低一点线密到正常水平，破百帧应该是可以的（其实FPS这个参数对我们已经没有太大意义）。后期把改进点A和C做了，比较期待其效率表现。

至于数千帧的处理速率，其实是个噱头，因为每帧扫查数据量很少，做平面波HFPS上千帧其实对系统的压力没有看上去那么大，后面做平面波时我需要压力测试一下，但我预感是能够达到的。

在相同参数配置和硬件配置下，真正重要的是全链路整体的数据吞吐率！

再然后，本次更新还添加了相控阵探头GPU版本的基本处理，在EchoSight框架下连接软件层面工作正常，之前CPU版本的问题先暂时没管，GPU图像与CPU配置下类似（错都错得类似，见2.12版本）

图像肯定是有问题的，几何关系扭曲，对比分辨率的圆球不圆，最上面的三个靶点位置也扭曲的。

相控阵探头的图像异常，让我很困惑，突然有一天半夜想到了一种可能性，修改程序验证，果然明显改进，修改前后对比

圆球比之前正常多了，靶点位置也基本水平了，特别是最顶上那几个点，改进非常明显。修改是在前端控制非常细节的地方，我认为对线阵也会有帮助，回头我再去线阵上实验对比一下区别。其实这也在另一个侧面确认了，我这边仿真输入与真实情况非常接近，这才可能在仿真上也发现这种前端问题。

现在我从图像结果上看还是有感觉哪里有不对的地方，计划认真分析一下。结果不出意外Murphy's Law（如果担心有问题，那几乎肯定会出问题）再次生效，问题找到了，细节不便展开。

再再然后，相控阵探头的MLA的修改也完成了。中间出了很多状况，忽略过程看最后结果，这些问题还是解决了，关闭与开启多MLA的结果如下

还是老情况，只能说未见明显异常，没法说能完全确认完全正确。

最后，就是处理相控阵情况下的合成孔径了。由于相控阵探头的特殊性，合成孔径处理过程中，图像在某些细节部分出现不太理想的结果。具体细节不展开，结果是基本解决了，虽然过程很曲折痛苦，改进结果还是不错。相控阵6MLA下6次合成孔径的结果，改进前后对比如下

修正后相比修正之前，图像的全场的一致性，信噪比，几何关系准确性都进一步提高。这对合成孔径的帮助是满显著的，特别是合成孔径是重点，在现有合成孔径基础上的提升都非常有价值。另外，在工程上我想到两个思路，我觉得可能会帮助到相控阵再提升那么一丢丢的图像IQ，我现在还不太确认结果会怎样。但是，现在后面的事还很多，先暂时不做，后面有机会我再来实验。

另外，图像远场部分的效果不太理想，应该是焦点太近了。即使是RTB搭配合成孔径，心脏探头的焦点也应当稍微远一点。

2.20更新总结：

1. 进行了一次全面的全链路系统性能分析，确认了A/B/C三个可能改进的方向；

2. 完成了改进点B重构优化，全链路性能（数据吞吐率）提升10%，达到4.5GBytes/Sec；

3. 添加了相控阵探头GPU版本的波束合成，连接链路，软件层面匹配正常；

4. 相控阵探头基础图像扭曲定位到了两个问题，并都已解决，图像未发现异常；

5. 完成相控阵探头多MLA，图像未发现异常；

6. 研究相控阵探头多MLA对合成孔径的影响，完成了工程方案，明显提升了图像的IQ；

下一步继续研究相控阵，因为相控阵情况比较复杂。在某些特别设置情况下（例如8MLA，2次合成孔径等配置），还有图像不理想的情况，如果相控阵能处理得比较理想，凸阵就更容易了，回头对以前的线阵也有帮助。

2.21 相控阵继续

（2024年04月06日）

这段时间接着研究相控阵，这真是一个天坑。发现20版本中的通道数据有点问题，这次重新修正了数据，再接着搞。如果在相控阵下用聚焦波，且焦点在场内，只要是自主研发的系统工程师都知道图像会最优，优于发散波和平面波，但这个里面的坑也最大，不容易设计开发平衡各方面的工程方案。这也是为什么在合成孔径的情况下，有点厂商在用发散波替代或直接绕过。

我觉得是做得到的，只是不知道我自己做得到不。目前，我还没有完全爬出这个坑，但已经爬到坑的边上了。直接看最新结果吧（20版本时，有提到8MLA的2次合成孔径配置就有点问题，这次我正怼着问题对比，下图是8个MLA配合8次合成孔径，且焦点在场内的结果，用的新的数据，两组结果数据相同。第一幅图是20版本方案的图像，第二幅图是最新方案的结果，增益略有差异，但这不是当前的重点，关注基础图像）。