nikonp

We are, careers page post might just not be up yet

Rerun co-founder here. Rerun doesn’t have replay in the sense of you send messages in and can play back the same messages in the same order later. We have playback in the sense that you can play it back in the viewer. We also have apis for reading back data but its more focused on dataframe use cases rather than sending you back messages

There is a native version as well: https://rerun.io/docs/getting-started/installing-viewer

You can for instance install and open the viewer natively with just:

> pip install rerun-sdk

> rerun

Thanks for sharing and that makes me really happy to hear. Keeping Rerun simple to use and easy to get started with has been a goal of ours from the beginning.

> I think Rerun should actually make the timeline view just another "view"

This is something we've talked about on and off internally and mostly all agree it's the right thing to do at some point. I also think there is a lot of things we could do to increase the usefulness of the timeline view even further so glad you're getting alot out of it already.

> Also we already have infrastructure to log and for live telemetry streaming so we don't integrate with the SDK directly in the deployed software and instead just have an adaptation layer to take logs or live data and push it through the Rerun SDK.

This is actually quite a common case and we don't have the ambition to make the Rerun SDK be the perfect logging library for all usecases. We're trying to do more instead to make it easier write efficient adapters that run elsewhere in your infra for cases where using the logging SDK isn't the best fit. The recent `rr.send_columns` API is in that direction but there will be more in the future

Thanks a lot I really appreciate you writing this out! I'd say most of your requests are things we'd like to address in the future. Built in screen recording is a common request and something I think makes sense for the open source project. A lot of the other requests require a central service of some kind to achieve high performance and/or a smooth user experience so those fall into the bucket of what will go into our commercial offering.

The many entities performance is still not where we'd like it to be. We've made multiple improvements over the last releases so worth kicking the tires again but it isn't solved in a fundamental way yet. There is still some low hanging fruit available to speed things up for many common cases of high cardinality by expanding our APIs slightly I believe. Those can come sooner that a bigger architecture update so hopefully that will be enough for your use case

Yeah that makes sense, we hear that a lot and it's on our roadmap. It won't come in the next release unfortunately but I'd love to have it land within the next couple releases after that

When was the last time you tried it? This was the focus of the 0.18 release, which improved the situation quite significantly (see https://rerun.io/blog/column-chunks for details)

Thanks!

Just so you know you can log rr.SeriesPoint(color=(0, 0, 255), marker_size=1.5) in the same call as rr.Scalar(peak.value) if you want. You could also skip logging the rr.SeriesPoint altogether and include it in your blueprint (as a component override or default). That way you can more clearly separate styling from data. Either way I hear you on the added complexity. At the end of the day it came down to trading off simplicity vs expressiveness on this one.

Totally hear you on the "make it easier to have AI that doesn't hallucinate" thing. We should definitely do something in that area. Just haven't managed to get the cycles in to do so yet

Glad to hear you like Rerun and thanks for the suggestions!

> A little worrying for me that rerun seems getting more complicated and verbose and API changes frequently.

We'll unfortunately continue to change some APIs over the next few releases. We're working towards stabilizing the format soon and want to make sure it's in a form that will last.

Do you have any examples of changes you found to be more complicated? We've been trying to maintain the approach of providing a very simple high level API but then exposing more lower level APIs over time for more power and/or control. Would love to learn where we could be doing better there.

> The whole vizualization code can clutter algorithm/code that is begin debugged.

This is a bummer to hear for sure. One of the motivating experiences behind starting Rerun was how much system bloat home grown debugging and visualization infrastructure can bring. Any chance you could share examples that are less clean than ideal? (either here, discord, github or dm on any platform is fine)

Awesome to hear it's working out for you!

Emil had already started egui long before we started Rerun. The immediate mode paradigm of egui also fits very well with how we wanted to archetype Rerun. In addition to that the GUI framework story in Rust is still quite immature which means you often need to be able to make changes to the actual GUI framework if you want to create a "cutting edge" UI heavy product in Rust. Not surprisingly you therefore see other Rust based apps build their own GUI frameworks for that same reason. There are some promising initiatives in the Rust world but we'd still make the same decision to build on egui today if we were to start from scratch.

That's totally doable but we haven't put together any examples of that kind other than perhaps this one https://rerun.io/examples/generative-vision/llm_embedding_ne..., which uses UMAP to project some text embeddings vectors to 3D

Sorry to hear that. Mind sharing what it was you were trying to do? Most users find Rerun to be very fast when trying to do the things it was built for.

Super glad to hear that!

What are some things you're missing on the client/server streaming? I'm aware that there is much to do but would love to hear your specific issues

Really glad to hear you like what we've been building so far! I personally appreciate the note on the strong data model in particular since that's taken up a lot of focus and effort.

In that case it will make you glad to hear that we are currently working on support for encoded video! The new (time) column oriented APIs that came in the latest 0.18 release was (among other things) a building block for video by allowing users to send data that extends over time to Rerun in a single call. You can expect something on the encoded video front within a release or two.

Rerun ceo here, thanks for jumping into the discussion here Adrian!

First of, want to really highlight that MCAP is a great container format for robotics message recordings. We (like most of the robotics community) see it as the natural evolution of the rosbag format (co-created a while back by one of our team members).

To add onto some of the differences between Rerun and Foxglove, the Rerun open source project is focused on a viewer that runs completely client side. It's written end-to-end in Rust for maximum speed and portability. That means it can run fully natively for maximum speed (e.g. utilizing native threads and rendering APIs), and in the browser via wasm. You can even embed Rerun visualization in your own web apps and use it inline in python notebooks.

I would also highlight the SDK, which lets you log / send data easily from your own code without up front declaring a message schema. This makes it much easier to also use for quick debugging etc (although some of the largest companies in the world use it to build large sets of different internal visualization heavy tools as well).

On the data model side we've focused on developing what you might label a language or semantic data model. We believe this gives users significantly more power and control than "only" orienting around robotics messages. I think that's why you'll see Rerun being used in a lot more contexts than viewing Robotics messages (although that's a big use case as well). In order to really make use of that data model (with high performance) we've had to develop a new database query engine and a lot of other craziness.

We do have a cloud data platform in the works that leans heavily on our semantic model and query engine. It will have a different take to Foxglove's, with a much broader view of the full data lifecycle for embodied AI.

Awesome to hear you're enjoying it! Anything we could do to make you love it even more?

Rerun CEO here. Awesome to hear you're enjoying using Rerun for monitoring ML training runs!

> I will say the (not so recent) API change to "components" and "archetypes" hasn't clicked for me yet. Obviously I could sit down and figure it out.

Are you referring to the move from the `rr.log_image("path/to/my_image", ...)` style API to the `rr.log("path/to/my_image", rr.Image(...))` style API that came in 0.9 (roughly a year ago)? Our intention was that if you stick to the higher level Archetype APIs, the two should be equivalent in terms of "magically handle any data". The component level APIs are intended to give more control when you need it (for instance to improve performance), but aren't required.

> But it would be a lot nicer if the API could just ingest whatever damn types I throw at it, rather than raising an error 20-minutes in because I wasn't polite enough.

Our intension is for this to never happen either, but obviously "any data" is a very broad set of things so there may be some mistakes on our side. If you're not running the SDK in strict mode, any thrown exception from the Python SDK should be seen as a bug. Really sorry to hear that happened, I agree that sucks. Would love any details you can share on when any aspect of Rerun is annoying (either here, on discord, or github)!

One of the founders of Rerun here. I don't remember exactly where the idea came from but I think it was basically two things. First off, creating chunks of columns to store or pass around is a pretty common approach in data systems. Parquet files have the concept of row groups for instance which is pretty similar (main difference is that chunks don't have to include all columns). Second, it was just quite obvious that we needed to amortize the fixed costs better for small data somehow

Did you read the post?

Cool! I don’t know Ramer-Douglas-Pecker, how did that work?

Thanks! Haha yeah definitely the downside of putting disclaimers everywhere.

There is another order of magnitude performance left to squeeze out in theory so I guess we can always leave it in until that’s done too

Thanks for the heads up! Looking into it. Haven't been able to reproduce yet on mobile or desktop safari but that error message helps

Ah yeah that was definitely a usecase we hadn’t thought of. Really cool project!

Cool! Where was that? (I’m on the Rerun team so curious)

One of the founders here. I totally see where you’re coming from. If you come from a world where log equals text, then using log for anything else seems strange.

In robotics and autonomy, “log” is commonly used for e.g. sensor data or planning decisions as well. But even outside those fields it isn’t uncommon to talk about logging metrics for instance.

Still, no metaphor is perfect and we have spent a lot of time discussing what word to use. “Record” gives me the sense that the main purpose is to save the data for later. Rerun is also about the live use case. There words like “stream” or “send” could work perhaps.

In the end we decided on “log” because it is short, is already used in a similar way in some of the areas we hope Rerun will be used, and because data can either be stored on disk and/or be streamed/uploaded somewhere (like with regular text logs).

Thanks! It will be fun to hear what people think after giving it a try

Thanks! Will fix!

Hey marcind,

Thanks alot! And same to you! sharetheboard looks cool =). The physical world has so many benefits, it's really such a waste not to use it.

We haven't really done any specific testing to figure out the max distance away from a surface to share. But it definitely works in room scale settings.