How is "*.rds format" read it by CC ?

[Rolling]

I work with Rielg TLS, CC handle very well all the workflow. One of the advantages is to read the *.rds format keeping part of the information of the scan such as [xyz] coordinate, Reflectance [dB], Amplitude [dB], Deviation, Flags. All the scalar fields match to the data exported by Riegl soft(Ascii) except the Reflectance [dB].

For CC the reflectance range 0.01 to 655.32

Rds.JPG (204.25 KiB) Viewed 1648 times

For Riegl soft reflectance range -20.33 to 0.69

txt.JPG (201.11 KiB) Viewed 1648 times

What transformation was used to get those results?

Thanks in advance.

[daniel]

Hum, if the RDS files are read by the 'old' Riegl filter (the one I developed myself) then I remember having discussed about this field with someone from Riegl because I found the values to be 'strange' but he told me that they looked fine... Compared to the values you get with the exporter, I bet the values displayed in CC are not really 'dB'. I just don't know what is the right transformation...

Otherwise the other filter (the 'new' one) has been developed by Riegl and is probably more reliable. But I believe it is meant to read RDBX files.

[Rolling]

Thank you very much, CC is a great soft.

By the way, I just notice the CC only read the positives values in [dB] units then is applied a linear transformation ( y = x - {~655.36} ) for the negatives [dB] values.

For CC values {0.01, 0.34, 0.69}, 635.03 ......... 655.32
For the exporter (Ascii) values -20.33 .............. -0.04, {0.01, 0.34, 0.69}

These number {0.01, 0.34, 0.69} are the same in both cases.

That's why the histograms seem like this:

Histograms.jpg (75.22 KiB) Viewed 1610 times

[daniel]

Do you have any idea of what the correct transformation would be?

[Rolling]

To be honest, I do not know what might be the correct transformation, but if all values >= 100 (to make sure not delete the true values read for CC) is subtracted by 655.36. The result is pretty close to the value from the exporter. It can not be the same due to the large decimal in the values. However, is not the real solution.

histo.jpg (90.73 KiB) Viewed 1577 times

[daniel]

Okay I fixed that in the code. It will be available in the next (beta) release.

Even though it's not 'perfect', it's still better than the previous version ;). Many thanks for the feedback and the tests.