尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
Rerun 类型系统中的 `Count` 组件:通用计数值的定义、编码与 MCAP 统计应用
Rerun 类型系统中的Count组件通用计数值的定义、编码与 MCAP 统计应用【免费下载链接】rerunVisualize, query, and stream to train on multimodal robotics data.项目地址: https://gitcode.com/GitHub_Trending/re/rerunCount是 Rerun 类型系统re_types中一个通用的计数值组件用于统计消息messages、模式schemas、通道channels等实体的数量。本文围绕 Count 组件文档结合仓库内的类型定义源码、SDK 生成代码与 MCAP 统计解码器完整讲解它的数据模型、Arrow 编码方式、跨语言使用方式以及它在McapStatistics原型中的真实落地场景。读完本文你将能够在 Python / Rust / C 三种 SDK 中正确构造与记录Count组件并理解 MCAP 文件统计数据从磁盘到 Rerun 数据流的完整链路。一、组件定位什么是Count根据 count.md 的定义Count是一个通用计数值a generic count value文档原文明确指出它用于统计消息、模式、通道等各种实体的数量Used for counting various entities like messages, schemas, channels, etc.。值得注意的是该类型在文档中被标记为unstable不稳定⚠️This type isunstableand may change significantly in a way that the data wont be backwards compatible.这意味着Count的表示方式或语义在未来版本中可能发生不兼容的改动在将其用于长期存储或对外发布的数据时需要留意这一兼容性风险。在 Rerun 的类型体系里Count是一个组件component——它是挂在实体路径entity path上的一个原子数据单元本身没有独立的可视化逻辑而是作为原型archetype的字段参与数据组织。从源码结构看count.rs 中它的 Rust 定义是一个repr(transparent)的元组结构体内部直接包装一个编码类型#[derive(Clone, Debug, Copy, PartialEq, Eq, PartialOrd, Ord, ::re_byte_size::SizeBytes)] #[repr(transparent)] pub struct Count(pub crate::encodings::UInt64);repr(transparent)意味着它在内存布局上与内部UInt64完全一致不引入任何额外开销同时它实现了Deref/DerefMut见 count.rs因此可以直接把它当作一个UInt64来读取和修改。二、数据模型与编码UInt64 与 Arrow 类型Count的核心特征非常简洁——它是一个64 位无符号整数。文档中给出了两层信息Rerun 编码UInt64对应 uint64.md 中定义的64 位无符号整数编码类型Arrow 数据类型UInt64。也就是说Count在序列化到 Arrow 列时直接映射为原生UInt64数组没有任何中间包装。这一设计在 Python 绑定中体现得尤为明显count.py 中Count直接继承自encodings.UInt64class Count(encodings.UInt64, ComponentMixin): **Component**: A generic count value. Used for counting various entities like messages, schemas, channels, etc. ⚠️ **This type is _unstable_ and may change significantly in a way that the data wont be backwards compatible.** _BATCH_TYPE None # Note: there are no fields here because Count delegates to encodings.UInt64配套的CountBatchcount.py则声明了组件类型标识rerun.components.Count负责批量数据的序列化。由于继承了UInt64Count天然支持int字面量作为别名输入类型定义文件中的#[python(aliases int)]在 Python 侧使用时可以直接传普通整数无需手动包装。选型上使用UInt64而非有符号整数的原因也很直观计数消息数、模式数、通道数等在语义上天然非负且 64 位范围足以覆盖绝大多数场景下的超大计数值。三、从类型定义到跨语言绑定Count 的代码生成链路Rerun 的组件类型并不是在三种语言中各自手写的而是通过单一类型定义源文件驱动代码生成。Count的权威定义位于 count.def.rs/// A generic count value. /// /// Used for counting various entities like messages, schemas, channels, etc. #[rerun::rerun_type] #[python(aliases int)] #[python(array_aliases int | npt.NDArray[np.uint64])] #[rerun(state unstable)] #[rust(derive(Copy, PartialEq, Eq, PartialOrd, Ord))] #[rust(repr transparent)] pub struct Count { pub value: rerun::encodings::UInt64, }这个文件并非可执行代码而是由re_types_builder解析的类型 DSL文件头有明确注释It is parsed byre_types_builderto generate the Rust, Python and C bindings。几个关键注解的含义#[rerun(state unstable)]标记类型为不稳定对应文档中的兼容性警告#[python(aliases int)]Python 侧允许直接用int作为别名构造#[python(array_aliases int | npt.NDArray[np.uint64])]批量构造时支持 numpy 的uint64数组#[rust(repr transparent)]Rust 侧采用透明表示零开销包装。生成产物即上文提到的 count.rsRust、count.pyPython以及 C 头文件中的rerun::components::Count。这也是 Rerun 保证三种语言 SDK 类型语义完全一致的根本机制。四、核心应用场景作为McapStatistics原型的必填字段Count的用武之地集中体现在 McapStatistics 原型 中——它是该原型当前唯一的直接使用者。McapStatistics用于描述一个 MCAP 录制的录制级统计信息其定义见 mcap_statistics.def.rs将 6 个必填计数字段全部声明为Count字段组件类型语义message_countCount录制中包含的数据消息总数不含元数据、模式定义等其他记录schema_countCount录制中唯一模式定义的数量channel_countCount录制中定义的通道数量每个通道代表一个主题与编码组合attachment_countCount内嵌的文件附件数量如标定文件、配置数据等metadata_countCount提供录制环境等上下文信息的元数据记录数量chunk_countCount用于组织消息的数据块chunk数量此外原型还包含message_start_time、message_end_time两个Timestamp字段界定整个录制的起止时间以及可选的channel_message_counts按通道细分的消息计数由ChannelMessageCounts组件承载——其内部每个ChannelCountPair同样包含一个基于UInt64的message_count。这些字段在定义中均标记为#[rerun(required)]且#[rerun(no_ui_edit)]表明它们必须提供、但不需要用户手动编辑。McapStatistics的 Rust 生成代码 mcap_statistics.rs 为每个字段提供了独立的ComponentDescriptor例如message_count的描述符为McapStatistics:message_count、组件类型为rerun.components.Count见 mcap_statistics.rs。该原型可以在 DataframeView 中展示适合对多份录制进行批量对比分析。五、底层实现MCAP 统计解码器如何填充 CountCount并不仅是手工记录数据的类型Rerun 的 MCAP 导入管线也会自动生成它。核心实现在 stats.rs 的McapStatisticDecoder中该解码器从 MCAP 文件的 summary section 读取mcap::records::Statisticsctx.summary().stats通过from_statistics()将统计记录逐字段转换为McapStatistics原型message_count、schema_count、channel_count等全部作为u64计数写入Count组件结果被封装进一个以TimePoint::STATIC标记的Chunk写入固定的实体路径__mcap_properties代码注释明确The results will be stored at__mcap_properties每条录制只记录一次若文件缺少统计信息则输出re_log::warn_once!(Could not access MCAP statistics information.)警告后跳过。值得留意的是解码器对channel_message_counts的处理展示了Count语义的可组合性它将 MCAP 的通道 ID 与计数值配对为encodings::ChannelCountPair { channel_id, message_count }见 stats.rs再批量构造成ChannelMessageCounts组件。这意味着你既可以得到全录制总量Count也可以按通道拆分的明细计数。该解码器还带有单元测试stats.rs测试断言解码输出恰好生成 1 个 chunk、实体路径为__mcap_properties且 chunk 是静态is_static()的——这验证了统计数据以静态时间点写入的行为。六、实战在 Python / Rust / C 中记录 Count结合Count的语义最直接的实战方式是通过McapStatistics原型记录一份 MCAP 录制的概要统计。以下三段代码来自仓库 docs/snippets/all/archetypes/ 下的官方示例展示了三种语言的等价写法。Pythonmcap_statistics_simple.pyLog simple MCAP recording statistics. import rerun as rr rr.init(rerun_example_mcap_statistics, spawnTrue) rr.log( mcap/statistics/recording_overview, rr.McapStatistics( message_count12500, schema_count3, channel_count5, attachment_count2, metadata_count8, chunk_count25, # 2024-04-01 00:00:00 UTC in nanoseconds message_start_time1743465600000000000, # 2024-04-01 00:10:00 UTC in nanoseconds (10 minute recording) message_end_time1743466200000000000, ), )得益于#[python(aliases int)]Python 侧直接传普通整数即可rr.McapStatistics内部会自动将它们映射为Count组件时间字段以纳秒级整数表示。Rustmcap_statistics_simple.rs//! Log simple MCAP recording statistics. fn main() - Result(), Boxdyn std::error::Error { let rec rerun::RecordingStreamBuilder::new(rerun_example_mcap_statistics) .spawn()?; rec.log( mcap/statistics/recording_overview, rerun::McapStatistics::update_fields() .with_message_count(12500u64) .with_schema_count(3u64) .with_channel_count(5u64) .with_attachment_count(2u64) .with_metadata_count(8u64) .with_chunk_count(25u64) .with_message_start_time(1743465600000000000i64) // 2024-04-01 00:00:00 UTC in nanoseconds .with_message_end_time(1743466200000000000i64), // 2024-04-01 00:10:00 UTC in nanoseconds (10 minute recording) )?; Ok(()) }Rust 使用构建器模式update_fields()配合with_*方法计数字段显式标注u64类型通过FromT泛型实现见 count.rs自动转换为Count。Cmcap_statistics_simple.cpp// Log simple MCAP recording statistics. #include rerun.hpp int main(int argc, char* argv[]) { const auto rec rerun::RecordingStream(rerun_example_mcap_statistics); rec.spawn().exit_on_failure(); rec.log( mcap/statistics/recording_overview, rerun::archetypes::McapStatistics::update_fields() .with_message_count(12500) .with_schema_count(3) .with_channel_count(5) .with_attachment_count(2) .with_metadata_count(8) .with_chunk_count(25) .with_message_start_time(1743465600000000000 ) // 2024-04-01 00:00:00 UTC in nanoseconds .with_message_end_time( 1743466200000000000 // 2024-04-01 00:10:00 UTC in nanoseconds (10 minute recording) ) ); }记录完成后这些统计会在 DataframeView 中以表格形式呈现便于横向对比多个录制的规模消息数、通道数、时长等。七、使用注意与边界基于上述源码与文档信息使用Count时有几点值得注意不稳定类型Count与McapStatistics均标记为 unstable跨版本的数据兼容性不做保证count.md无符号语义Count是UInt64负值或浮点计数不适用若需统计对象数量以外的标量值应选择其他合适的组件类型不可直接可视化Count属于visualizer_none类型的载体组件见 mcap_statistics.def.rs 中的#[rerun(visualizer_none)]自身没有图形可视化器主要服务于表格视图与查询场景自动生成的场景导入 MCAP 文件时McapStatisticDecoder会自动在__mcap_properties实体路径下生成统计 chunk无需手工记录手工记录则适合在自行构造统计数据如模拟数据、跨录制汇总时使用查询与检索由于Count映射为原生 ArrowUInt64列在 DataframeView 或基于 DataFusion 的查询中可以直接参与数值比较、排序与聚合。综上Count是 Rerun 类型体系中小而专的组件数据模型只有一层UInt64却通过McapStatistics原型与 MCAP 解码器支撑起了录制级统计这一完整功能链路是理解 Rerun 组件-原型-编码三层架构的一个典型切入点。【免费下载链接】rerunVisualize, query, and stream to train on multimodal robotics data.项目地址: https://gitcode.com/GitHub_Trending/re/rerun创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
RELATED

相关推荐

Velero Restore Resource Modifiers 完全指南:JSON Patch、Merge Patch 与默认资源修饰器

Velero Restore Resource Modifiers 完全指南:JSON Patch、Merge Patch 与默认资源修饰器

Velero Restore Resource Modifiers 完全指南:JSON Patch、Merge Patch 与默认资源修饰器 【免费下载链接】velero Backup and migrate Kubernetes applications and their persistent volumes 项目地址: https://gitcode.com/GitHub_Trending/ve/velero 导读…

📅 2026/9/16 17:49:03
电机控制工程师实战能力地图:从FOC到无感控制

电机控制工程师实战能力地图:从FOC到无感控制

1. 为什么2027届秋招的电机控制岗,正在从“可选项”变成“必争项”我带过三届校招季的嵌入式方向实习生,去年帮一家中型工控企业筛了87份电机控制方向的简历。结果发现一个反直觉现象:投递人数比前年涨了42%,但真正能讲清楚FOC矢量…

📅 2026/9/16 17:44:03
local-deep-research 的 ADR-0003 决策实录:拒绝普遍强制 `raise ... from e`,以异常链断链守护 PII 安全

local-deep-research 的 ADR-0003 决策实录:拒绝普遍强制 `raise ... from e`,以异常链断链守护 PII 安全

local-deep-research 的 ADR-0003 决策实录:拒绝普遍强制 raise ... from e,以异常链断链守护 PII 安全 【免费下载链接】local-deep-research ~95% on SimpleQA (e.g. Qwen3.6-27B on a 3090). Supports all local and cloud LLMs (llama.cpp, Ollama,…

📅 2026/9/16 17:44:03
MORE NEWS

更多资讯

📰

使用 AWS CLI 的 codebuild batch-get-reports 批量获取 CodeBuild 测试与覆盖率报告详情

使用 AWS CLI 的 codebuild batch-get-reports 批量获取 CodeBuild 测试与覆盖率报告详情 【免费下载链接】aws-cli Universal Command Line Interface for Amazon Web Services 项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli 导读 本文围绕 AWS CLI 中 a…

📰

子域名收集与爆破原理实战:从DNS解析到工具链应用

做安全评估或者资产梳理的时候,我听到最多的一个问法就是:“这个目标到底有多少个子域名?”主域名往往只是门面,真正承载业务的、风险最高的是那些散落在各个环境里的子域名——测试站点、管理后台、旧版接口、第三方系统&#xf…

📰

Docker部署OnlyOffice中文菜单全链路配置指南

1. 项目概述:为什么非得用Docker部署OnlyOffice并配中文菜单? 我第一次在客户现场接手OnlyOffice部署时,踩了整整三天坑——Java环境版本不匹配、Nginx反向代理路径写错两处、locale语言包漏装、甚至因为系统时区没同步导致JWT令牌校验失败报…

📰

DeepSeek V4.1 Flash本地部署:显存估算与vLLM/SGLang启动指南

前两周我准备把 DeepSeek V4.1 Flash 正式接入内部推理服务之前,先在测试机上完整过了一遍本地化部署流程。网上关于这套模型的讨论很散,要么只有显存截图,要么只丢一句启动命令,真正能把显存需求、vLLM/SGLang 启动命令和四条部署…

📰

知识图谱驱动的旅游智能推荐系统实现

简介:这是一套基于Python后端与Vue.js前端构建的智能旅游推荐系统完整代码,面向计算机专业本科生及初学者,聚焦餐饮旅游领域知识图谱的实际应用,解决个性化景点、美食与行程推荐问题,适用于毕业设计、课程设计及期末大…

📰

GroundingDINO 零样本目标检测:给一句自然语言,就把图里的东西框出来

GroundingDINO 零样本目标检测:给一句自然语言,就把图里的东西框出来 【免费下载链接】GroundingDINO [ECCV 2024] Official implementation of the paper "Grounding DINO: Marrying DINO with Grounded Pre-Training for Open-Set Object Detecti…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬