Out of expediency, we added a JPEGBuffer to the TensorBuffer enum.
This means that any code working with TensorData needs to potentially support (or at least explicitly detect and not support) JPEG-Encoded data.
This leads to patterns such as wrapper types like https://github.com/rerun-io/rerun/blob/main/crates/re_types/src/tensor_data.rs#L392
The right way to handle this is to make ImageEncoded its own archetype which contains its own buffer type along with proper meta-information about the encoded format.
While it would be nice to handle this generically with "component-data-conversions" this refactor is likely still worthwhile as the image part could explicitly add support for this archetype (as it already handles 3 archetypes as is), and the Tensor space-view won't have to worry about it at all.
Out of expediency, we added a JPEGBuffer to the TensorBuffer enum.
This means that any code working with TensorData needs to potentially support (or at least explicitly detect and not support) JPEG-Encoded data.
This leads to patterns such as wrapper types like https://github.com/rerun-io/rerun/blob/main/crates/re_types/src/tensor_data.rs#L392
The right way to handle this is to make ImageEncoded its own archetype which contains its own buffer type along with proper meta-information about the encoded format.
While it would be nice to handle this generically with "component-data-conversions" this refactor is likely still worthwhile as the image part could explicitly add support for this archetype (as it already handles 3 archetypes as is), and the Tensor space-view won't have to worry about it at all.