-
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
Support YUY2-encoded images #4877
Conversation
I want to improve the rust api for logging images with a different encoding than the traditional rgb and resolve #4820 in the process, but I'm not sure what the best approach would be for this. One thought is to implement some helper methods on |
166a90c
to
abbb72a
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.
Nice work! Can go in as-is once we figured out the CI kinks, if you want I can take care of it.
The only wrinkle here is that we nowhere specify that this is the YUY2 variant (YuYv instead of uYvY) for the format. I don't know how common the other one is, but https://en.wikipedia.org/wiki/YCbCr#4:2:2 mentions both.
Also, just like with NV12 before we don't have these documented anywhere. I tried to find a nice spot to put doctext in the fbs files, but codegen isn't picking that up yet, so we'll have to do this as a follow-up.
It's also a bit sad how many places needs to be touched to get this going, something to re-conciliate for us in the future.
That said, as an extension to status quo this looks perfect 👌
I'll sort it asap, I want to get my local environment set up so I can easily fix CI stuff in the future, seems like my python formatter is producing some different output.
Yea, @YukumoHunter also mentioned this. The gist linked in #3541 specifically used YUV422, so I based it on that. I think renaming it to YUY2 over YUV422 might be better? WDYT? |
Hmm yeah let's rename it to |
Co-Authored-By: Harold <37922636+yukumohunter@users.noreply.github.com>
e9b75dc
to
3e8f48a
Compare
Alright, I've renamed it to |
} else { | ||
// we're on an odd pixel, so we need to sample the second y value | ||
// we add 2 to the column to get the second y value | ||
y = f32(textureLoad(texture, vec2u(uv_col + 2u, uv_row), 0).r); |
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.
Didn't notice either at first, but this offset is wrong actually. We already muliplied the uv_col with 2, so it points at the Y value right now. I found out when adding yuy2 to the (former) nv12 python test script which also highlighted that there was still some stuff missing in ImageEncoded
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.
Great work and extra thanks for further cleaning up the conversion code both in wgsl and Rust!
When trying to test this I found that extension for ImageFormat
etc. was still missing and once I added that it looked a bit off, highlighting that there was a small mistake in the offset calculation for Y.
I think it's all good now and ready to go, but can you please confirm first with your own dataset that this checks out?
Hmm looks like the row is offset every second pixel or so, strange! |
not entirely sure what's up with the python wheel builds, but it's obviously not this pr's fault. Things work for me locally so what could possibly go wrong. Time to merge! |
… and avoid crash on chrome (#3931) (#5074) ### What When we added support for YUY2 format in (#4877) we we re-triggered the issue originally originally reported in #3931 and now #5073 - This is a more extreme version of: #3948 which was the workaround the first time we hit this. ### Checklist * [x] I have read and agree to [Contributor Guide](https://github.com/rerun-io/rerun/blob/main/CONTRIBUTING.md) and the [Code of Conduct](https://github.com/rerun-io/rerun/blob/main/CODE_OF_CONDUCT.md) * [x] I've included a screenshot or gif (if applicable) * [x] I have tested the web demo (if applicable): * Using newly built examples: [app.rerun.io](https://app.rerun.io/pr/5074/index.html) * Using examples from latest `main` build: [app.rerun.io](https://app.rerun.io/pr/5074/index.html?manifest_url=https://app.rerun.io/version/main/examples_manifest.json) * Using full set of examples from `nightly` build: [app.rerun.io](https://app.rerun.io/pr/5074/index.html?manifest_url=https://app.rerun.io/version/nightly/examples_manifest.json) * [x] The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG * [x] If applicable, add a new check to the [release checklist](tests/python/release_checklist)! - [PR Build Summary](https://build.rerun.io/pr/5074) - [Docs preview](https://rerun.io/preview/e35e3a58e1f2093140d4d63479098124f6556463/docs) <!--DOCS-PREVIEW--> - [Examples preview](https://rerun.io/preview/e35e3a58e1f2093140d4d63479098124f6556463/examples) <!--EXAMPLES-PREVIEW--> - [Recent benchmark results](https://build.rerun.io/graphs/crates.html) - [Wasm size tracking](https://build.rerun.io/graphs/sizes.html)
What
This PR Introduces support for YUV422/YUY2 encoded images based on #3541.
The raw (encoded) image data is stored in an R8Uint texture. The contents of the texture get decoded in the
rectangle_fs.wgsl
via the decoder written indecodings.wgsl
.Other YUV image formats could be added easily, following the NV12 implementation with slight modifications to the decoder.
Checklist
main
build: app.rerun.ionightly
build: app.rerun.io