-
Notifications
You must be signed in to change notification settings - Fork 366
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BGR(A) image format support #7238
Conversation
Deployed docs
|
fff7b02
to
6fc111c
Compare
…e BGR directly (tested all scripts touched here)
6fc111c
to
78d1f4c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⭐
(ColorModel::BGR, ChannelDatatype::U8) => { | ||
( | ||
pad_rgb_to_rgba(&image.buffer, u8::MAX).into(), | ||
TextureFormat::Bgra8Unorm, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is using the Bgra8Unorm
texture even a good idea, or is it just adding complexity?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from the pov of the all knowing rectangle shader it's just extra complexity, so I should add a comment for the rationale of doing this anyways!
The reason is that this allow us to use BGR(A) on meshes and other occasions where we today don't have fancy decoding etc..
This is very very subtly hinted at by the behavior of required_shader_decode
which the mesh visualizer uses to determine if it should warn the user that it can't consume a given image.
(in the glorious 🌈 future 🌈 re_renderer will have an internal conversion pipeline that will allow us to do texture conversions separately and gpu accelerated on the fly for all types. But we live in the now and gotta squeeze out the 80% with what we have 😄)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for the code, cleaned up and more formalized :)
// Make use of wgpu's BGR(A)8 formats.
//
// From the pov of our on-the-fly decoding textured rect shader this is just a strange special case
// given that it already has to deal with other BGR(A) formats.
//
// However, we have other places where we don't have the luxury of having a shader that can do the decoding for us.
// In those cases we'd like to support as many formats as possible without decoding.
//
// (in some hopefully not too far future, re_renderer will have an internal conversion pipeline
// that injects on-the-fly texture conversion from source formats before the consumer of a given texture is run
// and caches the result alongside with the source data)
//
// See also [`required_shader_decode`] which lists this case as a format that does not need to be decoded.
What
Adds a checklist item that goes through all the different format to make sure they run properly - this looks a bit overzealous, but in fact we are using the fact that wgpu has special support for 8bit bgr images in order to support them on meshes (this detail is tbf untested as of now!), so going through our formats in a test has quite some merit.
(aaalso I think it's the only place where we actually check now that all datatypes still work fine 😳 )
("ethnically sourced lena picture", courtesy of Morten Rieger, https://mortenhannemose.github.io/lena/)
Speaking of meshes: the mesh texture support story is now spelled out better, showing warnings and ignoring textures if they're in an unsupported format.
Checklist
main
build: rerun.io/viewernightly
build: rerun.io/viewerCHANGELOG.md
and the migration guideTo run all checks from
main
, comment on the PR with@rerun-bot full-check
.