DracoPy
DracoPy copied to clipboard
seung-lab
Draco Submodule Should Point to Exact Version
I'm trying to use DracoPy to encode point clouds, and send them to a frontend I have, where they are decoded using Draco again (but in typescript, so with Three.js, not DracoPy). I used to do this by writing to temporary files using the draco binaries, reading from the files, and sending over those bytes. This worked, but I'd much prefer to just use DracoPy.
When I encode and decode using DracoPy, it works well. However, when I encode using DracoPy, and then decode using TypeScript, the colors get all messed up. My only working theory is that the Draco versions that DracoPy is incompatible with the one I am using on my frontend, which is believable because the snapshot of Draco that DracoPy points to isn't an exact version. Thus, the submodule should point to: https://github.com/google/draco/commit/bd1e8de7dd0596c2cbe5929cbe1f5d2257cd33db, rather than https://github.com/google/draco/commits/befe2d880992e6fdbfd29fe20a3b8664460b92cd.
Note: the specific way in which the colors are screwed up is that they are being interpreted as 0-1 when they are being sent as 0-255.
Hi Zevbo,
This seems like a very good suggestion! Would you mind trying to compile DracoPy like that and see if it fixes it for you?
Sounds reasonable. I've cloned DracoPy to my machine and have the reference to the correct draco. How can I now recompile DracoPy?
Shouldn't be too difficult hopefully! Make sure you have cmake installed and just do python setup.py develop if you are on windows or linux. If you are on a Mac, especially an M1 or M2, edit ./build-macos-arm.sh to work with your existing virutalenv and then run it. It will generate fat binaries that work on x86 and arm64.
Wasn't too dificult, but alas it didn't fix my issue. This raises the concern that this is a different bug, though one I don't know the source of. Just to recount what I've seen:
- I can encode a PCD using DracoPy than decode it with the 1.5.2 draco_decoder binary from draco, and colors are correct
- If I decode it using three.js, also pointed to the 1.5.2 decoder, the colors are treated as if they are on a 0-1 scale, when they are really on 0-255, meaning all colors are either on or off
- With the point cloud I am currently trying to encode, the 25th byte in the drc file is 1. Using the draco_encoder binary, it is a 0. This is the only difference, and when I switch it back, colors are decoded correctly.
Wondering if somehow DracoPy accidentally encodes in that bit that it is a 0-1 scale?
Hi Zevbo,
Good detective work! Hopefully I can look into this more in a bit, but check out this PR in the meantime. It might have a clue.
https://github.com/seung-lab/DracoPy/pull/32