Karim Abou Zeid
@kabouzeid.bsky.social
Those are awesome, thanks for the inspiration
November 10, 2025 at 9:37 PM
Those are awesome, thanks for the inspiration
So you uv sync -p 3.13 the first time (if you care about the exact version), and then you never need to pass it again. The existing venv “soft pins” its python version until you explicitly request a different version, either via CLI or updated constraints of the python version.
September 30, 2025 at 6:27 AM
So you uv sync -p 3.13 the first time (if you care about the exact version), and then you never need to pass it again. The existing venv “soft pins” its python version until you explicitly request a different version, either via CLI or updated constraints of the python version.
I use it all the time, super useful :) It won’t pin, just makes sure your venv uses this python version if it doesn’t already or doesn’t exist yet.
September 30, 2025 at 6:23 AM
I use it all the time, super useful :) It won’t pin, just makes sure your venv uses this python version if it doesn’t already or doesn’t exist yet.
What’s the reason for pinning in general? I somehow never found a use case for it. If I want a specific version from that range, I provide it in uv sync on demand.
September 29, 2025 at 10:29 PM
What’s the reason for pinning in general? I somehow never found a use case for it. If I want a specific version from that range, I provide it in uv sync on demand.
Very good read, thanks for writing this up :)
September 21, 2025 at 10:36 AM
Very good read, thanks for writing this up :)
Does it still happen when you compile before DDP? I always use DDP as the outermost wrapper, there is too much hacky stuff going on in its forward and backward for my liking.
September 10, 2025 at 9:15 PM
Does it still happen when you compile before DDP? I always use DDP as the outermost wrapper, there is too much hacky stuff going on in its forward and backward for my liking.
The normal metrics in Tab. 1 also don’t match. I checked only for DSINE, and here the actual metrics are considerably better than in Tab 1. Also missing some sota normal methods. Tab 3 is only a small subset of common benchmarks, and on 1/2 of the datasets it’s worse than both VGGT and MoGe.
July 25, 2025 at 7:06 AM
The normal metrics in Tab. 1 also don’t match. I checked only for DSINE, and here the actual metrics are considerably better than in Tab 1. Also missing some sota normal methods. Tab 3 is only a small subset of common benchmarks, and on 1/2 of the datasets it’s worse than both VGGT and MoGe.
Same, I don’t want to use them anymore now, and if I “have to”, then I’m writing them as triple dashes ---. At least semicolons are still safe 👀
July 21, 2025 at 6:51 AM
Same, I don’t want to use them anymore now, and if I “have to”, then I’m writing them as triple dashes ---. At least semicolons are still safe 👀
In my mind, I often associate instance seg with fancy depth clustering.
June 17, 2025 at 7:59 AM
In my mind, I often associate instance seg with fancy depth clustering.
I like the look. DINOv2, DUSt3R, CroCo v2, and GB are misspelled if you want to fix those.
April 13, 2025 at 11:27 AM
I like the look. DINOv2, DUSt3R, CroCo v2, and GB are misspelled if you want to fix those.
I haven’t experienced that yet, but I’m not sure if I’ve tried on that many files. Which one did you try: `dua a` (or just `dua`) will block and finally print, which can take a long time. `dua i` starts an interactive TUI and loads everything in the background while you can already start inspecting.
April 10, 2025 at 7:29 AM
I haven’t experienced that yet, but I’m not sure if I’ve tried on that many files. Which one did you try: `dua a` (or just `dua`) will block and finally print, which can take a long time. `dua i` starts an interactive TUI and loads everything in the background while you can already start inspecting.
Looks good. I haven’t seen it before. Can also recommend this one: github.com/Byron/dua-cli
GitHub - Byron/dua-cli: View disk space usage and delete unwanted data, fast.
View disk space usage and delete unwanted data, fast. - Byron/dua-cli
github.com
April 10, 2025 at 7:09 AM
Looks good. I haven’t seen it before. Can also recommend this one: github.com/Byron/dua-cli
Ah yes, you’re right, thanks for the reference! It’s really just a line in space without explicitly specifying a point on the line as its origin.
April 4, 2025 at 2:27 PM
Ah yes, you’re right, thanks for the reference! It’s really just a line in space without explicitly specifying a point on the line as its origin.
The origin is not lost though, it’s just encoded differently. In the end it’s still 6 dims, 3 for the direction and 3 for the origin. A bit unclear to me though what benefit this origin encoding brings.
April 4, 2025 at 1:38 PM
The origin is not lost though, it’s just encoded differently. In the end it’s still 6 dims, 3 for the direction and 3 for the origin. A bit unclear to me though what benefit this origin encoding brings.
Their proposed architecture only makes sense for a dense parameterization. I don’t think they ablate with other dense representations though.
April 4, 2025 at 9:17 AM
Their proposed architecture only makes sense for a dense parameterization. I don’t think they ablate with other dense representations though.
Correction: the origin is already encoded in the Plücker ray. I meant that DiffusionSfM encodes /both/ origin and endpoint.
April 4, 2025 at 8:46 AM
Correction: the origin is already encoded in the Plücker ray. I meant that DiffusionSfM encodes /both/ origin and endpoint.
I think the first time I saw Plücker rays was in the Camera as Rays paper arxiv.org/abs/2402.14817. The same authors also recently released DiffusionSfM, where they indeed keep the origins o as well.
Cameras as Rays: Pose Estimation via Ray Diffusion
Estimating camera poses is a fundamental task for 3D reconstruction and remains challenging given sparsely sampled views (<10). In contrast to existing approaches that pursue top-down prediction of gl...
arxiv.org
April 4, 2025 at 8:36 AM
I think the first time I saw Plücker rays was in the Camera as Rays paper arxiv.org/abs/2402.14817. The same authors also recently released DiffusionSfM, where they indeed keep the origins o as well.
Agree, einops or shape in comments is a must. Also, makes it much easier for others to read and understand the code without executing it.
March 30, 2025 at 1:17 PM
Agree, einops or shape in comments is a must. Also, makes it much easier for others to read and understand the code without executing it.
Maybe last one, could you try VGGT single-view on that image for direct comparison? 😁
March 20, 2025 at 9:15 PM
Maybe last one, could you try VGGT single-view on that image for direct comparison? 😁
True. Does MoGe do a better job at segmenting the sky here?
March 20, 2025 at 8:29 PM
True. Does MoGe do a better job at segmenting the sky here?
Hmm yes, not sure if the demo is bugged or if it didn’t correctly segment the sky 🤔 Do you have access to GPUs to test this locally?
March 20, 2025 at 8:20 PM
Hmm yes, not sure if the demo is bugged or if it didn’t correctly segment the sky 🤔 Do you have access to GPUs to test this locally?