e57 to rgb conversion

Discuss all FARO related issues here.
User avatar
Daniel Wujanz
I have made 100> posts
I have made 100> posts
Posts: 108
Joined: Fri Aug 24, 2018 11:26 am
Full Name: Daniel Wujanz
Company Details: technet GmbH
Company Position Title: 3D Laser Scanning Specialist
Country: Germany
Linkedin Profile: Yes
Location: Berlin
Has thanked: 44 times
Been thanked: 41 times
Contact:

Re: e57 to rgb conversion

Post by Daniel Wujanz »

Thanks for your comment, Jed!

First of all, I agree - it certainly depends what you're trying to achieve.

Where I disagree is the following argument (again, I'm not trying to start a war ; ) )
...where I'm more interested in the pixels as data, it makes more sense to convert the gridded scan topology directly to a pixel array rather than interpolating values on to a new pixel grid based on polar coordinates.


First thought - The elementary observations of 3D-scanners are: a distance, a direction and a tilt angle. Hence, these magic boxes are as polar as possible!

a) You've mentioned the scan topology - this information doesn't fall from heaven. So the question is, how does this information ends up in the file? The manufacturers did this work for you. Sometimes this information is correct - sometimes you have smaller or larger data gaps in between. If you need the correct positions in the image (or e.g. for 3D-triangulation in 2D space) then you have to go back into the world of the scanner - which is a polar one and not a new description.

b) Initially, there's no interpolation. All you do is to sort them into the grid. So there will be gaps that you can of course interpolate, if you so wish.

c) If you should make it to Intergeo this year I'd love to catch up for some bevies and some exchange of thoughts!

Long story short: my interpretation is the inverse of yours - for visualization purposes I'd naively trust the content of the gridded file. If I need reliable data, I'd generate the topology myself.

Cheers

Daniel
jedfrechette
V.I.P Member
V.I.P Member
Posts: 988
Joined: Mon Jan 04, 2010 7:51 pm
Full Name: Jed Frechette
Company Details: Lidar Guys
Company Position Title: CEO and Lidar Supervisor
Country: USA
Linkedin Profile: Yes
Location: Albuquerque, NM
Has thanked: 16 times
Been thanked: 63 times
Contact:

Re: e57 to rgb conversion

Post by jedfrechette »

Daniel Wujanz wrote: Thu Apr 30, 2020 10:04 am b) Initially, there's no interpolation. All you do is to sort them into the grid. So there will be gaps that you can of course interpolate, if you so wish.
Maybe I'm misunderstanding, but assuming you mean a regular angular grid, i.e. each row and column is separated by a monotonically increasing fixed angular increment, how would would you achieve this in practice? Specifically, how do you deal with the overlap region without averaging or interpolating? Similarly, since the scanner is likely rotating continuously I would expect the actual rotation values within a given column to vary continuously as well. At the bottom of a column your horizontal rotation might be 80 degrees, but at the top it might be 81.

When I referred to topology, I was simply referring to the implicit grid defined by how the scanner records data. Point #1 in Column #1 is adjacent to Point #2 in Column #1 and Point #1 in Column #2, etc. You'd need to query the actual coordinates for each of those points to determine the spatial relationships between them.
Jed
User avatar
Daniel Wujanz
I have made 100> posts
I have made 100> posts
Posts: 108
Joined: Fri Aug 24, 2018 11:26 am
Full Name: Daniel Wujanz
Company Details: technet GmbH
Company Position Title: 3D Laser Scanning Specialist
Country: Germany
Linkedin Profile: Yes
Location: Berlin
Has thanked: 44 times
Been thanked: 41 times
Contact:

Re: e57 to rgb conversion

Post by Daniel Wujanz »

Dear Jed,
...each row and column is separated by a monotonically increasing fixed angular increment
Correct, these are the predefined angular settings of the scanner.
Specifically, how do you deal with the overlap region without averaging or interpolating?
Ah, this is what you mean - my bad! In this case you have several options: a) take the first point that was sorted into a cell, b) take the last point... c) average all points that fall into a certain cell...
At the bottom of a column your horizontal rotation might be 80 degrees, but at the top it might be 81.
You're absolutely right! This is the physical nature of the sampling process and consequently has to be considered (and of course is when you're using polar coordinates).
You'd need to query the actual coordinates for each of those points to determine the spatial relationships between them.
Correct, yet this process is darn quick. Step 1: Cartesian to polar conversion, Step 2: Determine corresponding grid address and that's it. B.t.w. I'm using this procedure also to determine topological relations for triangulation.

All the best

Daniel
jedfrechette
V.I.P Member
V.I.P Member
Posts: 988
Joined: Mon Jan 04, 2010 7:51 pm
Full Name: Jed Frechette
Company Details: Lidar Guys
Company Position Title: CEO and Lidar Supervisor
Country: USA
Linkedin Profile: Yes
Location: Albuquerque, NM
Has thanked: 16 times
Been thanked: 63 times
Contact:

Re: e57 to rgb conversion

Post by jedfrechette »

Daniel Wujanz wrote: Mon May 04, 2020 8:37 am
...each row and column is separated by a monotonically increasing fixed angular increment
Correct, these are the predefined angular settings of the scanner.
This requires that you assume measurements are captured at fixed angular increments and I'm not sure that's a safe assumption. Under most situations the nominal angular scan resolution is going to be larger than the increment that the angular encoders are capable of measuring. Therefore, you need to either define your angular grid based on the nominal step size and potentially interpolate values on to that grid or define your grid based on the encoder step size and end up with a sparse image array. In many situations neither of those is ideal.

To give a concrete example of how this comes in to play the old Optech ILRIS scanners used an oscillating mirror to steer the beam through a z pattern to capture the scan window. One result of this was that at the left and right edges of the scan window the horizontal angular increment between points decreased because the mirror needed to slow down and then speed up while it reversed direction.

Admittedly, I haven't investigated this in detail for rotating mirror scanners, but I wouldn't be surprised at all if equivalent variability exists. I suspect from an engineering standpoint it is easier to measure the angular position of points than it is to guarantee that they're at a fixed spacing. If I want to do a scan with a resolution of 0.04 but my encoders measure in increments of 0.001, why wouldn't I measure angular positions with that higher precision?
Daniel Wujanz wrote: Mon May 04, 2020 8:37 am
Specifically, how do you deal with the overlap region without averaging or interpolating?
Ah, this is what you mean - my bad! In this case you have several options: a) take the first point that was sorted into a cell, b) take the last point... c) average all points that fall into a certain cell...
Those are certainly reasonable data reduction strategies, and like I said the best approach depends on what you're after. For us the simplest solution is to do the same thing the OP is doing. Simply convert the structured scan to an image based on its implicit grid structure. The 3D coordinates, whether cartesian or polar, just become additional pixel attributes, no different than color or intensity. A single 360 scan with overlap just becomes 2 separate quasi slit-scan images stored in the same wrapper.
Jed
Veit
I have made 10-20 posts
I have made 10-20 posts
Posts: 19
Joined: Sat Feb 15, 2020 10:13 pm
Full Name: Veit Streicher
Company Details: Navvis
Company Position Title: Technical Account Manager
Country: Germany
Linkedin Profile: Yes
Has thanked: 21 times
Been thanked: 2 times

Re: e57 to rgb conversion

Post by Veit »

Hi Marcus,
i was following the interesting chat and always impressed by people who write some line of code to solve their problem. Not sure what exactly you need to achieve with the RGB panoramic images. In case you need to do it on regular basis or need to use the panos to link to some modelling tools to simplify your workflow, please have a short look at our feature
youtu.be/Sg8QfrAqOxs

In case i got you wrong, all the best and happy coding :-)

Veit
Izanage
I have made <0 posts
I have made <0 posts
Posts: 1
Joined: Wed Oct 14, 2020 1:56 pm
Full Name: Albion
Company Details: Cydis
Company Position Title: dev DB
Country: France
Linkedin Profile: No

Re: e57 to rgb conversion

Post by Izanage »

Hi everyone,
I am trying to do the same as Marcus, generate(build) images from a structured E57 file.
I just discoverd this python library but that's not my strongest point and If I understood it correclty, I am not able to generate the pano images directly with only this lib.

I don't know if Marcus was able to reach his goal and I was wondering if he or anyone can help me out or share the code ?

I am open to any proposition.

Best regards,
Albion
jedfrechette
V.I.P Member
V.I.P Member
Posts: 988
Joined: Mon Jan 04, 2010 7:51 pm
Full Name: Jed Frechette
Company Details: Lidar Guys
Company Position Title: CEO and Lidar Supervisor
Country: USA
Linkedin Profile: Yes
Location: Albuquerque, NM
Has thanked: 16 times
Been thanked: 63 times
Contact:

Re: e57 to rgb conversion

Post by jedfrechette »

I just posted our approach to this task in a similar discussion here:

viewtopic.php?p=89206#p89206

Hopefully that can help point you in the right direction and I'm happy to try and answer any more questions that I can.
Jed
Post Reply

Return to “FARO”