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

header.point_format() is buggy for LAZ #27

Closed
hugoledoux opened this issue Jul 10, 2020 · 1 comment · Fixed by #28
Closed

header.point_format() is buggy for LAZ #27

hugoledoux opened this issue Jul 10, 2020 · 1 comment · Fixed by #28

Comments

@hugoledoux
Copy link

Same file in LAS and LAZ gives different answers; LAS is correct, LAZ obviously wrong since format>10.

Not sure if this is a bug here or for https://github.com/tmontaigu/laz-rs?

use las::{Read, Reader};
fn main() {
    let mut rs = Reader::from_path("/Users/hugo/data/ahn3/crop.las").unwrap();
    let mut rz = Reader::from_path("/Users/hugo/data/ahn3/crop.laz").unwrap();
    let pfs: u8 = rs.header().point_format().to_u8().unwrap();
    let pfz: u8 = rz.header().point_format().to_u8().unwrap();
    println!("=>{}", pfs);
    println!("=>{}", pfz);
}

=> 1
=> 129

@tmontaigu
Copy link
Contributor

The bug is in las-rs,

For LAZ files, laszip sets the most significant bit of the point format to 1 in the header to indicate compressed data, so for point format 1 the point format id becomes 1000_0001 (129) when it's a LAZ file.

The problem here is that in las-rs we return this compressed point format id in the public interface instead of returning the proper id and keeping the compressed fmt id internally only

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 a pull request may close this issue.

2 participants