今天堪称漫无目的的做了一个实验 一、DINOv3昨天了解到有一个东西叫做attention map，可以可视化模型对图像的注意力程度，我第一个想起来的是DINO这样的ViT编码器，去年发布的DINOv3，所以就想看看他到底能学到什么特征 一打开github，看到这张图还是挺唬人的，如果这样的细节信息可以通过学习得到，那光源和材质什么的应该不在话下吧~ 这张图是基于特征做余弦相似度，越相似的越亮，

刚到寝室准备摩拳擦掌开始训练呢，仔细一看SDM-UniPS作者不公开数据集，不公开训练代码…

近期炼丹比较迷茫，没有改进思路了，读了几篇论文感觉知识在大脑滑过也没留下什么，输入不如输出，索性写点东西，梳理一下。 一、模型能学到什么？前一段时间思考的问题是算力和先验的问题。VGGT的作者说：相信Data driver，我也相信，但是奈何算力不足，支撑不起庞大的模型，退而求其次转向设计先验特征。 在光度立体问题中，虽然先验信息很丰富，但是在所谓“通用”光度立体的问题下，意味着模型需要学习：

实验室的服务器没有公网IP，因此在外炼丹比较麻烦，因此使用frp将机器内网穿透出来 一、部署云应用服务器购买链接：应用详情 | 雨云 简单冲了30块钱，反点很高，冲30给了60，每月消耗6，30块钱用10个月，性价比很高了，想开的朋友可以用我的邀请码：OTg2Mjg5 1. 配置服务端信息开好云服务之后，点击管理 ->选择服务器 -> 配置文件 -> 12345678910111

现在的方案中，以开启相机为例，我要在/api/camera/start上发送{“action”: “start”}，然后在相机进程if action == “start”:，然后再去执行实际的start代码，这至少需要维护两对字典，可以说是非常的丑陋了 ZMQ确实是更好的通信方案，今天白天有点事情，今晚突击修改一下吧，希望在明天之前修改好并演示 今

再次感慨一下代码水平和项目管理还是差的太远太远了，想着用更好一点的框架，更成熟一点的驱动，有没有更好的方案，到头来写了改改了写，浪费时间 昨天重新简单规划了一下框架，今天在开始之前先简单规划一下需要修改的内容 之前相机进程之前是写的opencv的capture直接读取，这次改成用gst读取，并封装restart，这意味着要跨进程传递命令。 首先写一个进程间通信通道，实现主进程和相机进程通信，并控

新建了测试文件，今天打算用调用API打开、关闭相机 今天的主要工作是把web跑起来之后，封装了几个简单的接口，并能从外部控制相机的打开与关闭，因为fastapi在上一版本中已经很熟悉了，所以内容其实并没有多少，主要是做调试工作，比如会有一些偶发性闪退，我已经改掉了。这里主要是想聊聊控制链的逻辑 一、服务层最开始设计程序架构的时候我是试图把服务层去掉的，为什么要封装一下？代码跳来跳去的，又乱又不好理

一、Tee测试又又又简单封装了一下…每次新建一条支路都要重写tee，queue, valve 太麻烦了，封装成了一个_add_branch 123456789101112131415161718192021222324252627282930313233def _add_branch(self, downstream_bin: Gst.Element, drop: bool = True):

一、DEMO实现接下来自己手写一个管线，实现： 1234567891011source | v tee | +--> queue -> videoconvert BGR -> appsink(algo.py) | +--> queue -> mpph264enc -> filesink -> output.mp4 | +-

众所周知windows不兼容gnome，需要自行安装。pip install 需要编译，查阅了相关资料，咨询了AI，下面是安装过程： Getting Started — PyGObject官方教程推荐msys32，需要装一个新的python解释器，目测这个东西像一个linux虚拟机一样的东西 令人高兴的是conda支持直接安装，那我们接下来就开始吧 首先，启动conda-forge： 12cond