Tensor & depth image value ranges can now be configured, from UI & code

[Wumpf]

What

• Fixes Adjustable depth image range #6106
• Fixes Allow to specify a tensor's data range via component #2341
• NOT included here is image ranges, this PR is only about things affecting colormaps (Floating-point image data range seems to be assumed to be at least 0-255. #4624)

Depth images (and their clouds):

depth.image.range.editing.mov

Tensors:

tensor_data_range.mov

Noteworth ripple effects & considerations in this PR:

• turns out depth image constructor on Python missed a lot of parameters, fixed that
• went with a new ValueRange component rather than reusing Range1D because the semantics (and names in the ui) of the later were just too unclear
  • we need a tagged component mechanism really badly!
  • decided against putting this on the tensor view as some notes indicated was the plan
• ended up refactoring a few interesting things around image/tensor handling:
  • colormap is no longer part of ImageInfo, we already didn't use it for hashing it. Having now a range made it even more clear that this doesn't belong there
  • finite_range on tensor & image is now always present, using the datatypes' finite range as fallback. The None case handling was awkward at best and non-existant (error out) usually

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested the web demo (if applicable):
  • Using examples from latest main build: rerun.io/viewer
  • Using full set of examples from nightly build: rerun.io/viewer
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG
• If applicable, add a new check to the release checklist!
• If have noted any breaking changes to the log API in CHANGELOG.md and the migration guide

• PR Build Summary
• Recent benchmark results
• Wasm size tracking

To run all checks from main, comment on the PR with @rerun-bot full-check.

[github-actions]

Deployed docs

Commit	Link
90eb9fd	https://landing-do0mnbv92-rerun.vercel.app/docs

[emilk]

Very good!

My only concern is that we don't end up with a bad estimate and then stick with it. In particular, what is the estimated range of an image of a new space view, created when the time cursor is before the image was logged? Maybe it doesn't run the fallback/estimator in that case, and all is good?

[emilk]

Very good!

My only concern is that we don't end up with a bad estimate and then stick with it. In particular, what is the estimated range of an image of a new space view, created when the time cursor is before the image was logged? Maybe it doesn't run the fallback/estimator in that case, and all is good?

[Wumpf]

My only concern is that we don't end up with a bad estimate and then stick with it. In particular, what is the estimated range of an image of a new space view, created when the time cursor is before the image was logged? Maybe it doesn't run the fallback/estimator in that case, and all is good?

The behavior shouldn't have changed to before: If no value is present, we evaluate the fallback and fallbacks are not sticky - they get evaluated every frame. This means that we'll always grab the image stats that are available for that frame and those (other than my change regarding how finite_range is defined) are unchanged to before. Which should give us the same behavior.
Notably, this also means that until someone either logs or overrides an image range, they will still get flickering behavior if their depth image or tensor range changes over time.

not 100% sure that answers the question - does it? :)

[emilk]

Oh, perfect answer - thank you!