ImageBind —— 多模态 AI 模型
ImageBind 是支持绑定来自六种不同模态(图像、文本、音频、深度、温度和 IMU 数据)的信息的 AI 模型,它将这些信息统一到单一的嵌入式表示空间中,使得机器能够更全面、直接地从多种信息中学习,而无需明确的监督(即组织和标记原始数据的过程)。
ImageBind 通过将文本、图像/视频和音频、视觉、温度还有运动数据流串联在一起,形成一个单一的 embedding space,让机器能从多维度来理解世界,也能创造沉浸式的多感官体验。
ImageBind 通过将六种模式的嵌入对齐到一个共享的空间,实现了跨模式检索,这就能搜索那些没有同时出现的不同类型的内容。把不同的模式嵌入叠加,可以自然地构造它们的语义。例如 ImageBind 可以与 DALLE-2 解码器和 CLIP 文本一起嵌入,生成音频到图像的映射,就像人类听到声音脑补画面的那种感觉。
示例代码
跨模态(例如图像、文本和音频)提取和比较特征。
import data import torch from models import imagebind_model from models.imagebind_model import ModalityType text_list=["A dog.", "A car", "A bird"] image_paths=[".assets/dog_image.jpg", ".assets/car_image.jpg", ".assets/bird_image.jpg"] audio_paths=[".assets/dog_audio.wav", ".assets/car_audio.wav", ".assets/bird_audio.wav"] device = "cuda:0" if torch.cuda.is_available() else "cpu" # Instantiate model model = imagebind_model.imagebind_huge(pretrained=True) model.eval() model.to(device) # Load data inputs = { ModalityType.TEXT: data.load_and_transform_text(text_list, device), ModalityType.VISION: data.load_and_transform_vision_data(image_paths, device), ModalityType.AUDIO: data.load_and_transform_audio_data(audio_paths, device), } with torch.no_grad(): embeddings = model(inputs) print( "Vision x Text: ", torch.softmax(embeddings[ModalityType.VISION] @ embeddings[ModalityType.TEXT].T, dim=-1), ) print( "Audio x Text: ", torch.softmax(embeddings[ModalityType.AUDIO] @ embeddings[ModalityType.TEXT].T, dim=-1), ) print( "Vision x Audio: ", torch.softmax(embeddings[ModalityType.VISION] @ embeddings[ModalityType.AUDIO].T, dim=-1), ) # Expected output: # # Vision x Text: # tensor([[9.9761e-01, 2.3694e-03, 1.8612e-05], # [3.3836e-05, 9.9994e-01, 2.4118e-05], # [4.7997e-05, 1.3496e-02, 9.8646e-01]]) # # Audio x Text: # tensor([[1., 0., 0.], # [0., 1., 0.], # [0., 0., 1.]]) # # Vision x Audio: # tensor([[0.8070, 0.1088, 0.0842], # [0.1036, 0.7884, 0.1079], # [0.0018, 0.0022, 0.9960]])

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
每日一博 | 京东 APP 百亿级商品与车关系数据检索实践
导读 本文主要讲解了京东百亿级商品车型适配数据存储结构设计以及怎样实现适配接口的高性能查询。通过京东百亿级数据缓存架构设计实践案例,简单剖析了jimdb的位图(bitmap)函数和lua脚本应用在高性能场景。希望通过本文,读者可以对缓存的内部结构知识有一定了解,并且能够以最小的内存使用代价将位图(bitmap)灵活应用到各个高性能实际场景。 1.背景 整个汽车行业行特殊性,对于零配件有一个很强的对口特性,不同车使用的零配件(例如:轮胎、机油、三滤、雨刮、火花塞等)规格型号不一样。在售卖汽车零配件的时候,不能像3C家电、服饰,需要结合用户具体车辆信息,推荐适合的配件商品。基于此原因,京东自建人车档案模型并且利用算法清洗出百亿级的车型-零配件的适配关系数据,最终形成“人->车-〉货”关系链路,解决“人不识货”的问题。 具体使用场景如下图: . 图1.1京东商详推荐商品 图1.2京东加购弹窗推荐商品 2.数据模型 “人-> 车->货”关系的核心链路是由人(京东用户)、乘用车和SKU这三部分组成。 首先,用户在京东APP的商搜页、商详页多个位置都可以选择自己的车型信息...
- 下一篇
RHEL 10 不包含 X.org 显示服务器
红帽企业 Linux 发行版 RHEL 10 将不再包含 X.org Server。 官方文档称,X.org显示服务器已被弃用,并将在以后的主 RHEL 发行版本(从 RHEL 10 开始)中删除。目前的 RHEL 9 则仍包含 X.org 显示服务器,并会提供 10 年的支持,持续到 2032 年。 红帽没有解释弃用 X.org 的原因。但其实去年 Fedora 已经考虑删除旧版 X.org 驱动程序,当时红帽开发者 Adam Jackson 建议删除 VESA 和 FBDEV X.Org 驱动,以及从 X.Org Server 中删除导致使用这些驱动的相关支持代码。目的是远离 X11 并专注于 Wayland 支持。 现在,在大多数场景中,RHEL 默认桌面会话都是Wayland会话。X11协议仍完全支持使用XWayland后端。因此,需要X11的应用程序可以在Wayland会话中运行。 你也可以将用户会话切回到X.org后端。如需更多信息,请参阅选择 GNOME 环境和显示协议。
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- MySQL8.0.19开启GTID主从同步CentOS8
- Mario游戏-低调大师作品
- Linux系统CentOS6、CentOS7手动修改IP地址
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Docker快速安装Oracle11G,搭建oracle11g学习环境