Skip to content
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

fix(pcd): sizeSum calculation + rgb parsing #3101

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

jclaessens97
Copy link

Description

  1. rowSize calculation
    I tried to drop-in replace our PCDLoader with the @loaders.gl version, but I noticed a difference in the rowSize calculation for binary PCD's. When comparing to our version which was based on the threejs example, I noticed a difference in the calculation. Replacing it with that implementation makes this loader work for me as well.

  2. RGB calculation
    In the original three implementation, color need to be normalized between 0 and 1 by dividing by 255.0. Also the order of RGB needed to be reversed (BGR). This didn't happen for the binary version and the order was also wrong for the binary_compressed version.

I'll provide 2 binary PCD's that were broken in the original implementation, that are now fixed.

pcd.zip

@jclaessens97 jclaessens97 changed the title fix: sizeSum calculation + rgb parsing fix: sizeSum calculation + rgb parsing in PCDLoader Sep 27, 2024
@jclaessens97 jclaessens97 changed the title fix: sizeSum calculation + rgb parsing in PCDLoader fix(pcd): sizeSum calculation + rgb parsing Sep 27, 2024
@ibgreen
Copy link
Collaborator

ibgreen commented Sep 27, 2024

@jclaessens97 Thanks for the contribution.

  • Lint - Are you able to run yarn lint fix and push again? Unfortunately many good PRs get closed because linter issues don't get resolved...
  • Tests - It would be amazing if we could add a test file to loaders.gl and a test case as well, but the provided examples are a bit big to include in the repo, up to 1-2MB would feel more OK - just in case you have a smaller file on hand with compatible licensing.
  • Docs - Should there be a bullet in docs/whats-new.md?

color.push(dataview.getUint8(row + offset.rgb + 0));
color.push(dataview.getUint8(row + offset.rgb + 1));
color.push(dataview.getUint8(row + offset.rgb + 2));
color.push(dataview.getUint8(row + offset.rgb + 2) / 255.0);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree that using normalized colors is better. However this is a breaking change and should probably be mentioned in docs/upgrade-guide.md.

I am on the fence if it is worth it, but we could avoid breaking if we offered a pcd.normalizeColors loader option on the PCDLoader.

I have some concerns that we have code that creates a typed array from this array and if that typed array is Uint8Array it might fail (all values will be 0 or 1). Not sure if it is easy for you to find, I will try to dig more into this when I find some time.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, I'm perfectly fine by adding a normalizedColors option to avoid the breaking change!

Not sure what you mean by the last section about the Uint8Array. I think this is not applicable when we introduce a new array, right?

About the linting, I think I already ran the linter before pushing, but I can check again.

I wasn't able to run the tests so far. I had 2 failing thests from scratch, something to do with the paths I think, so if you have any pointers here, I'm happy to add some more tests with smaller examples!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what you mean by the last section about the Uint8Array. I think this is not applicable when we introduce a new array, right?

There is code in loaders.gl that can convert parsed data to e.g. binary representations, in which case it might copy this JS array into a Uint8Array.

I'd have to dig into exactly what is implemented for meshes in terms of conversion right now to verify if it is an issue at this time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants